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REVISION ONE OF DECISION No. 12/05 ON STANDARDIZATION OF 
LOGICAL FORMATS FOR THE EXCHANGE OF DIGITAL DATA 

AMONG STATES PARTIES 



This decision standardizes the logical data formats for exchange of digital data 
recorded during observation flights, for analogue recorded data converted to digital following 
observation flights, and for any other forms of digital data using the Open Skies Digital Data 
Exchange Format (OSDDEF) whose exchange has been approved by the OSCC. The formats 
specified in this decision conform to the Basic Image Interchange Format (BIIF) standard 
(International Organization for Standardization (ISO) 12087-5:1998 and its published 
Corrigenda items). 

Whereas the original text of OSCC Decision No. 12/05 specified the version of the 
Open Skies Digital Data Exchange Format (OSDDEF) known as "OSDDEF 1.0", this 
revision of OSCC Decision No. 12/05 specifies two additional versions of OSDDEF to be 
known as "OSDDEF 1.1" and "OSDDEF 1.2". 

In addition, this revision of OSCC Decision No. 12/05 permanently retires the 
"OSDDEF 1.0" version of the logical format. This act of retirement means that the 
"OSDDEF 1.0" version of the logical format is no longer valid for use in generating 
Open Skies data after the date this decision goes into effect. 

SECTION I. DEFINITION OF TERMS 

The following definitions shall apply to terms used in this decision. 

The term "direct access medium", or "random access medium", means a storage 
medium in which data locations are found by going directly to their physical locations on the 
medium. In this decision, a direct access medium will be referred to as a "disk", for brevity, 
though it should be understood that this term encompasses digital recording media such as 
portable hard drives, portable solid state memory devices, and digital versatile disks (DVD). 

The term "physical format" means, an agreed combination of a file system and a 
peripheral bus. 
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The term "logical format" means the arrangement convention for data and data bits on 
a digital recording medium. "Logical format" is synonymous with the terms "digital data 
format" and "file format". 

The term "alphanumeric string", in the context of this decision, shall refer to any 
string of character data formed from the subset of displayable characters as defined by the 
character encoding standard (e.g., ASCII, BCS-A, etc.) being used. The notation "OxNN", 
where "NN" is used to represent a pair of characters in the range "0" through "9" and "A" 
through "F", is used in this decision to denote a hexadecimal value for a character code in a 
given character set. For example, the notation "0x20" may be used to denote the blank space 
character code of the American Standard Code for Information Interchange (ASCII) character 
set. Likewise, the notation "OxOD" may be used to denote the ASCII Carriage Return 
character. 

The term "numeric string", in the context of this decision, shall refer to any string of 
character data, formed from a subset of the characters defined in a given character encoding 
standard, which can be used to represent a signed or unsigned number containing a radix 
point (note that the radix point is called the decimal point when using base ten numbers). 
Under this definition, a "numeric string" can contain characters representing the numerals "0" 
through "9", the positive sign "+", the negative sign and the full stop character "." as a 
radix point (base ten decimal point). Alphabetic characters commonly used in mathematics 
and the sciences to denote exponential notation, scientific notation, octal notation, 
hexadecimal notation, etc., are not allowed for use in "numeric strings" in data files; numbers 
recorded in these kinds of notations may be used in data files, but are to be considered as 
"alphanumeric strings" and treated accordingly. 

SECTION II. EXCHANGE MEDIUM AND FORMAT DESCRIPTIONS 

1 . EXCHANGE MEDIUM DESCRIPTION 

An Open Skies digital data exchange disk shall contain a Media Annotation file and a 
series of Image Data files, all formatted according to the same valid version of OSDDEF (i.e., 
all files on the media are recorded as either OSDDEF 1.1 or OSDDEF 1.2 formatted files). 
An Open Skies digital data exchange disk, for OSDDEF 1.2 formatted files, may also contain 
one or more Interface Control Documents (ICD) which provides information about any 
required or user-defined data present in any of the Image Data files on the exchange media. 
An Open Skies digital data exchange disk may also contain other forms of digital data which 
have been approved for exchange by subsequent decisions of the OSCC. 

For video and infrared cameras using a frame-imaging device, each Image Data file 
shall contain the data for one image (e.g., frame), in a single OSDDEF Image Segment or as 
directed by any relevant Decisions adopted in the future. For video cameras using a 
line-imaging device, infra-red line-scanning devices, and SAR radar images, each Image Data 
file shall contain a single OSDDEF Image Segment containing an image with no more lines 
than as permitted by the required annotation interval in accordance with Decision Number 
Eight to the Treaty on Open Skies and any relevant Decisions adopted in the future. 
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2. OSDDEF IMAGE DATA FILE FORMAT DESCRIPTION 



The following paragraphs describe, in general terms, the structure of an Image Data 
file. This discussion applies equally well to both the OSDDEF 1.1 and OSDDEF 1.2 versions 
of the logical format. 



(A) Each Image Data file shall contain a File Header, a single Image Segment, and 
one or more Text Segments. The File Header stores information about the 
identification, structure, and content of the file, including the byte sizes for 
each of the data structures included in the file. Each Image Segment and Text 
Segment consists of a segment subheader that contains information describing 
characteristics of the data stored in that segment and a data field that contains 
the data itself. The OSDDEF specification permits the use of only one kind of 
Data Extension Segment (DES) known as the Tagged Record Extension 
Overflow (TREOVERFLOW) DES. The TREOVERFLOW DES may be 
used to provide additional space for Tagged Record Extensions (TRE); see 
Figure 1. 
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Figure 1: Open Skies Digital Data Exchange Format Image Data File Structure (note 
that for OSDDEF 1.1 Text Segments, nnn = 001) 



(B) The File Header and each segment subheader are composed of a number of 
data fields. The meaning of each data field is inferred from its position in the 
file and, in some cases, by the particular values stored in one or more 
preceding fields. The first four bytes of any OSDDEF file must contain the 
alphanumeric character string "OSDE". The remaining fields of the File 
Header and segment subheaders are then parsed by reading the value in the 
next data field, and, if appropriate, using it to determine the nature of 
subsequent data fields. Alphanumeric character string data elements shall be 
followed by the appropriate number of blank spaces to fill the field size. 
Unsigned numeric character data elements shall be stored as character strings, 
preceded by an appropriate number of zero characters ("0") to fill the field 
size. Signed numeric character data elements shall be stored as character 
strings, with an appropriate number of zero characters ("0") inserted between 
the sign and the numeric value to fill the field size. (Thus, for example, to 
place a value of +3.3 in a 5-character numeric field, one would write "+03. 3", 
not "0+3.3"). 

(C) Image data is stored immediately following the Image Segment Subheader. 
The image data may be organized by blocks (tiles) and/or by bands. Blocks 
(tiles) are non-overlapping rectangular sub-arrays of pixel values which act as 
contiguous sub-images making up the full image contained in the Image 
Segment. Put another way, an image consists of the union of one or more 
non-overlapping blocks (tiles). Bands are arrays of homogeneous data types, 
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such as the red channel in an RGB image. Within a block (tile) or band, data is 
organized in row-major order (i.e., first pixel of the first row, followed by the 
second pixel of the first row, and so on) starting with the upper leftmost pixel 
in the block (tile) or band. Multi-byte values shall be coded in order of 
significance, beginning with the most significant byte and ending with the 
least significant byte. 

(D) OSDDEF allows for additional non-image data to be included in the Image 
Data file. This may be implemented through the use of Tagged Record 
Extensions (TRE), which provide a means to record additional attributes about 
standard data segments not contained in the standard File Header or subheader 
fields. If a series of TRE is too long to fit in its designated portion of the 
header or subheader, then all or some of the individual TRE that do not fit are 
placed in an associated TRE OVERFLOW Data Extension Segment (DES). 
Additional non-image data may also be included in the Image Data file 
through the use of Text Segments. 

(E) Required annotation shall be stored immediately following the segment 
subheader of the Text Segment designated as containing the Treaty-required 
Open Skies image annotation (TEXTID = "ANNOTATION" and 
TXTITL = "OPEN SKIES IMAGE ANNOTATION"). The content and 
format of the required image annotation text data for OSDDEF 1.1 formatted 
files are specified in Annex E of this decision. The content and format of the 
required image annotation text data for OSDDEF 1.2 formatted files are 
specified in Annex F of this decision. 



3. OSDDEF MEDIA ANNOTATION FILE FORMAT DESCRIPTION 



The following paragraphs describe, in general terms, the structure of a Media 
Annotation file. This discussion applies equally to the OSDDEF 1.1 and OSDDEF 1.2 
versions of the logical format. 



(A) A Media Annotation file shall contain a File Header and one or more Text 
Segments. The File Header stores information about the identification, 
structure, and content of the file, including the byte sizes for each of the data 
structures included in the file. Each Text Segment consists of a segment 
subheader that contains information describing characteristics of the data 
stored in that segment and a data field that contains the data itself. The 
contents and formatting of the Media Annotation file Text Segment 
Subheaders are described in Annex D of this decision. 
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Figure 2: Open Skies Digital Data Exchange Format Media Annotation File Structure 
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(B) The File Header and each Text Segment Subheader are composed of a number 
of data fields. The meaning of each data field is inferred from its position in 
the file and, in some cases, by the particular values stored in one or more 
preceding fields. The remaining fields of the File Header and Text Segment 
Subheaders are then parsed by reading the value in the next data field and, if 
appropriate, using it to determine the nature of subsequent data fields. 
Alphanumeric character string data elements shall be followed by the 
appropriate number of blank spaces to fill the field size. Numeric character 
data elements shall be stored as character strings, preceded by an appropriate 
number of zero characters ("0") to fill the field size (Note that for numeric 
values, any additional zero characters are placed between the sign character, if 
present, and the numeric field value). 

(C) For the Media Annotation file, per Section II, paragraph 1, of Annex B of the 
Treaty, treaty-required media annotation text, as specified in Appendix 1 to 
Annex B of the Treaty, shall be stored immediately following the Text 
Segment Subheader of the first Text Segment designated as containing the 
Treaty-required Open Skies media annotation data (TEXTID = "MEDIA 
HDR" and TXTITL = "OPEN SKIES MEDIA ANNOTATION"). The content 
and format of the required media annotation text data for OSDDEF-formatted 
files are specified in paragraph 2 of Section VI of this decision. The character 
set used to record text data in Media Annotation files shall be the BCS-A 
character set (characters from the Basic Latin Collection ranging from 0x20 to 
0x71 •). 

SECTION III. OPEN SKIES DIGITAL DATA EXCHANGE FORMAT (OSDDEF) FILE 
CONTENT 

The following paragraphs describe the structure of the tables used to specify both the 
OSDDEF 1 . 1 and OSDDEF 1 .2 digital file formats. 

1 . ORGANIZATION OF LOGICAL FORMAT DESCRIPTION TABLES 

The tables in Annexes A through E and Annex G of this decision are organized 
according to the following structure: 

(A) The first column in each table identifies the name of the data field; 

(B) The second column specifies the allowable data field value or range of values. 
In those cases where the actual value of the data field varies depending upon 
the nature of the data stored in that element, a range of allowable values is 
indicated in the table instead; 

(C) The third column in the tables specifies the size of the data field value in bytes 
and whether the data is to be treated as an alphanumeric string or as a numeric 
string ("alphanumeric" data values shall be left justified and padded with 
spaces and "numeric" data values shall be right justified and left-padded with 
zeros as necessary); 

(D) A brief description of the data element is provided in the fourth column; 
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(E) The last column of each table indicates whether a field is required ("R") to be 
in the file or is conditional ("C") based on the particular value of another data 
element. For example, if there is only one band in the image in a particular 
file, then the value of the NBANDS field in the Image Segment Subheader is 
set to a value of "1" and the fields labeled IREPBAND2, ISUBCAT2, etc. 
(which are conditional based on there being more than one band in the image) 
are not included in that file. 

Tables and figures are provided in Annexes A through G to describe the 
OSDDEF-formatted File Header, Image Segment Subheader, Text Segment Subheader, SAR 
Information Parameters Tagged Record Extension template ("ccSARn" TRE), User-Defined 
TRE template, Image Annotation Text Segment Data for OSDDEF 1.1, Image Annotation 
Text Segment Data for OSDDEF 1.2, User-Defined Text Segment template for OSDDEF 1.2, 
and the TREOVERFLOW Data Extension Segment Subheader. 

2 . REQUIREMENTS FOR USER-DEFINED FIELD DEFINITIONS 

For each user-defined value included in an Open Skies Digital Data Exchange Format 
1 .2 file field, the State Party, or group of States Parties, generating that value shall provide 
the information required to fully and unambiguously interpret it, as part of the information in 
the Certification Technical Document and in the ICD files provided on the exchange media. 
User-defined fields should use field names and units used in the Open Skies Notification 
Formats and other Treaty documents when such field names and units exist. 

SECTION IV. TAGGED RECORD EXTENSIONS 

This decision provides for the use of the construct known as a Tagged Record 
Extension (TRE). 

1 . LOCATIONS FOR RECORDING TAGGED RECORD EXTENSIONS 

In OSDDEF 1.1, the only additional annotation data that may be included is the 
additional information found in Table C2 of Annex C of this decision associated with SAR 
imagery (I CAT = "SAR " in Table Bl of Annex B of this decision). In this case, the 
information in Table C2 shall be provided as Tagged Record Extension (TRE) data, which 
shall be recorded in one of the following places: the User-Defined Image Data (UDID) field 
of the Image Segment Subheader or in the Extended Subheader Data field of the Image 
Segment Subheader (IXSHD). 

When using the OSDDEF 1.2 version of the specification, the data provider may 
choose to provide non- image information through the use of Tagged Record Extensions 
(TRE), in which case the data shall be recorded in one or more of the following places: the 
User-Defined Header Data (UDHD) field of the OSDDEF File Header, in the User-Defined 
Image Data (UDID) field of the Image Segment Subheader, in the Extended Subheader Data 
field of the Image Segment Subheader (IXSHD) or Text Segment Subheader (TXSHD), and 
in one or more corresponding TRE Overflow Data Extension Segments (TRE OVERFLOW 
DES) in the case where sufficient space is not available in the UDHD, UDID, IXSHD, or 
TXSHD fields. 
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2. REQUIREMENTS FOR USER-DEFINED TAGGED RECORD EXTENSION 
FIELD DEFINITIONS 

While the TRETAG, TREL, and TREDATA fields are included in the OSDDEF 
specification to identify the name and length of a TRE, additional information must be 
provided by the developer(s) of the TRE in order for States Parties to be able to make use of 
the data provided in the TRE. For each TRE included in an OSDDEF file, the developer(s) of 
the TRE shall provide the information required to fully and unambiguously interpret it, as 
part of the information in the Certification Technical Document and in the ICD files provided 
on the exchange media. 

SECTION V. TEXT SEGMENT DATA 

This decision provides for the use of Text Segments. This decision includes a specific 
template in Annex E for Text Segment data to be used by States Parties in recording required 
Image Annotation information in OSDDEF 1.1 formatted Image Data files; this Text 
Segment is known as the "OPEN SKIES IMAGE ANNOTATION" Text Segment. 

Image Data files which are OSDDEF 1.2 compliant may also employ a Text Segment 
to record required Image Annotation information (although the required annotation may be 
provided in a user-defined TRE instead). The allowed precision and format for required 
annotation information provided in an OSDDEF 1.2 formatted Image Data file must conform 
to the requirements of the Treaty, the decision on annotation of data collected during an 
observation period and future decisions, but is otherwise user-defined and must be fully and 
unambiguously defined in an accompanying ICD file. Any Text Segment used in an 
OSDDEF 1.2 formatted Image Data file for recording required annotation information shall 
be identified by a TXTITL field value of "OPEN SKIES IMAGE ANNOTATION" in the 
Text Segment Subheader, per Annexes D and F of this decision. 

Furthermore, this decision provides for the inclusion of User-Defined Text Segments 
(Text Segments other than the "OPEN SKIES IMAGE ANNOTATION" Text Segment 
developed by the data provider) in OSDDEF 1.2 compliant Image Data files, as will be 
addressed in paragraph 2 of this Section. 

1 . USE OF TEXT SEGMENT CONSTRUCTS IN OSDDEF FILES 

Annex D of this decision defines the general format for any Text Segment Subheader 
in any OSDDEF files. The value of the TXTITL field identifies the type of data in the text 
data segment. 

The only Text Segments allowed for use in OSDDEF Media Annotation files are the 
TXTITL = "OPEN SKIES MEDIA ANNOTATION" Text Segments, as described in 
Section VI of this decision. 

The only Text Segment allowed for use in OSDDEF 1.1 compliant Image Data files is 
the TXTITL = "OPEN SKIES IMAGE ANNOTATION" Text Segment, based on the 
template described in Annex E of this decision. This Text Segment format is not allowed for 
use with OSDDEF 1.2 compliant Image Data files. 
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One of the Text Segments allowed for use in OSDDEF 1.2 compliant Image Data 
files is the TXTITL = "OPEN SKIES IMAGE ANNOTATION" Text Segment based on the 
template described in Annex F of this decision. This Text Segment structure is not allowed 
for use with OSDDEF 1.1 compliant Image Data files. In addition, OSDDEF 1.2 allows for 
the use of user-defined Text Segments in Image Data files to record non-image data as 
intended by Decision Number Nine of the Treaty and the decision on the annotation of data 
collected during an observation period. 

Data elements and their specification may be dependent on the type of sensor used. 
When using OSDDEF 1.2, the data provider may choose to provide any such required 
information through the use of user-defined Text Segments, but there is no requirement to use 
Text Segments to hold such required information. As described in Section IV of this decision, 
when using OSDDEF 1.2 the data provider may choose to create user-defined TRE to report 
this required information. 

2. REQUIREMENTS FOR USER-DEFINED TEXT SEGMENT DATA FIELD 
DEFINITIONS 

While the TEXTID and TXTITL fields are used in the OSDDEF specification of the 
Text Segment Subheader to identify the type and name of a Text Segment, additional 
information must be provided by the developer(s) of the user-defined Text Segment data in 
order for States Parties to be able to make full use of the data provided in the Text Segment. 
For each user-defined Text Segment, or user-defined portion of a standard OSDDEF 
annotation Text Segment template, included in an OSDDEF 1.2 file, the developer(s) of the 
user-defined Text Segment data shall provide the information required to fully and 
unambiguously interpret it, as part of the Certification Technical Document and in the ICD 
files provided on the exchange media, in accordance with the decision on the annotation of 
data collected during an observation period. 

SECTION VI. EXCHANGE MEDIUM CONTENTS 

The following discussion describes the types of files that are found on Open Skies 
digital data exchange media. Open Skies exchange media used to hold digital data files shall 
contain exactly one OSDDEF-formatted Media Annotation file and one or more 
OSDDEF-formatted Image Data files. One or more Open Skies Interface Control Documents 
(ICD) shall be included to describe the contents of any user-defined data structures present in 
OSDDEF 1.2-formatted files on the exchange media. 

1 . FILES SUPPORTING TREATY REQUIREMENTS FOR MEDIA EXCHANGE 

The following discussion outlines the types of files, other than OSDDEF-formatted 
Image Data files, present on Open Skies digital exchange media. 

(A) In order to fulfil the requirements of Annex B, Section II, paragraph 1, of the 
Treaty on Open Skies, each Open Skies digital data exchange medium ("disk") 
shall contain an OSDDEF-formatted Media Annotation file, the structure and 
contents of which are specified in Paragraph 2 of this Section. An 
OSDDEF-formatted Media Annotation file, which shall be named 
"OSyynnn MEDIA ANNOTATION.BIF", shall contain no Image Segments 
and one or more Text Segments. 
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(B) For OSDDEF 1.2, the exchange medium shall contain one or more Interface 
Control Document (ICD) files. There shall be an ICD file for each sensor 
configuration for which there are OSDDEF Image Data files containing TRE, 
user-defined Text Segments, and/or user-defined fields on the exchange 
medium. ICD files shall be named "config_ICD_version.TXT", where for a 
specific sensor configuration, the string "config" shall be replaced by the 
12-character name of the certified sensor configuration reported in the 
Notification Formats field SENSREFNUM, and the string "version" shall be 
replaced by a user-defined identifier which all States Parties can use to 
uniquely identify when new versions of ICD files are being supplied (For 
example, "RU SAR_ 0001_ICD_v01.TXT"). 

2. MEDIA ANNOTATION FILE DEFINITION 

A Media Annotation file, named "OSyynnn MEDIA ANNOTATION.BIF", shall 
consist of an OSDDEF-formatted Main File Header and one or more Text Segments. The 
data portions of the Text Segments are used to store the Media Annotation record for the 
observation flight mission. 

If the entire Media Annotation record is too large to fit in a single Text Segment, then 
the Media Annotation data shall be recorded across multiple Text Segments. When multiple 
Text Segments are needed, the Media Annotation record will be split along complete lines of 
text, as identified by a terminating Carriage Return and Line Feed pair (OxODOA). In this 
event, the Text Segments shall be placed in the Media Annotation file in consecutive order, 
such that the first Text Segment in the file shall record the first portion of the total Media 
Annotation record, the second Text Segment in the file shall record the second portion of the 
total Media Annotation record, and so on. 

The Text Data portions of the Text Segments of a Media Annotation file shall consist 
of the following 1 10-character lines of text, where each line contains a fixed-width field pair 
consisting of a 30-character label field, a 78-character data field, and a 2-character 
line-termination consisting of a Carriage Return (OxOD) and Line Feed (OxOA) character pair: 

(A) A Media Identifier string, consisting of a fixed-width field pair, where the first 
value is the literal string, "MEDIA LABEL ID: ", and the second value is a 
generated string of the form, "nnn_of_NNN", where "nnn" is a 3 -digit number 
representing the current medium, and "NNN" is a 3-digit number representing 
the total number of media (e.g., number of cassettes, drives, disks, etc.) used to 
record the Image Data files and any Interface Control Document (ICD) files 
for the mission (where "nnn" and "NNN" have a range of 001 to 999); 

(B) The total number of individual observing States Parties (and their associated 
observation flight reference numbers) associated with the observation flight 
mission, recorded as a fixed-width field pair, where the first value is the literal 
string, "NUMBER OF OBSERVING SP:", and the second value is a 
generated string of the form, "NN", where "NN" is a 2-digit number (where 
"NN" has a range of 0 1 to 99); 
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The following line, C, repeats once for each observing State Party associated with the 
current observation flight mission. 



(C) An observation flight reference number string, recorded as a fixed-width field 
pair, where the first value is the literal string, 

"OBSERVINGPARTYCC/OSFLT:", and the second value is a generated 
string of the form, "cc/OSyynnn", where "cc" is the country/group code of the 
observing party (from Table J. 1 in Annex J), "/" is a single solidus character 
(0x2F), and "OSyynnn" is an observation flight reference number defined as 
in the Treaty Annex B, Appendix 1, paragraph 1, and updated by OSCC 
Decision No. 4/10 (where "cc" is the country/group code of the current 
observer, the string "/OS" is as written, "yy" is the last two digits of the 
calendar year of the flight, and "nnn" is a unique three-digit number that 
identifies the flight); 

(D) The total number of States Parties over which the observation flight was 
conducted, recorded as a fixed-width field pair, where the first value is the 
literal string, "NUMBER OF OBSERVED SP:", and the second value is a 
generated string of the form, "NN", where "NN" is a 2-digit number (where 
"NN" has a range of 0 1 to 99); 



The following line, (E), repeats once for each State Party whose territory was 
observed and for which Image Data files and/or ICD files were recorded on the current 
medium. 



(E) The country/group code for the State Party or group of States Parties over 
whose territory the observation flight is taking place, recorded as a fixed-width 
field pair, where the first value is the literal string, "OBSERVED PARTY:", 
and the second value is a generated string of the form, "cc", where "cc" is the 
country/group code of the observed party (where "cc" is the appropriate code 
from Table J. 1 in Annex J); 

(F) Date of observation flight in Co-ordinated Universal Time to the nearest day, 
recorded as a fixed-width field pair, where the first value is the literal string, 

' 'D ATE OF OB SERVATIONFLIGHT : ", and the second value is a 
generated string of the form, "CCYYMMDD"; if an observation flight spans 
more than one day, the value recorded is the date when the observation flight 
first began (where "CCYY" is the four-digit year in the range 1991 to 9999, 
"MM" is the two-digit month in the range 01 to 12, and "DD" is the two-digit 
day in the range 01 to 31); 

(G) The total number of sensor configurations used during the observation flight 
for which Image Data files are stored on the current medium, recorded as a 
fixed-width field pair, where the first value is the literal string, 
"NUMBEROFSENSORSJJSED:", and the second value is a generated 
string of the form, "ss" (where "ss" ranges from 01 to 99 when Image Data 
files are present, or is 00 when the medium only contains ICD files associated 
with the current observation flight and no Image Data files are present); 
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The following lines, (H) through (P), repeat as a set for each sensor configuration 
associated with the observation flight for which Image Data files were recorded on the 
current medium; if no Image Data files associated with the observation flight are present on 
the medium (implying that the medium only contains ICD files associated with the 
observation flight), then lines (H) through (P) are omitted. 



(H) Sensor reference number, recorded as a fixed-width field pair, where the first 
value is the literal string, "SENSORUSED:", and the second value is a 
generated string of the form, "cc-rrrr-ssss" (where "cc" is the Open Skies 
two-character country/group code, per Table J. 1 in Annex J, associated with 
the Sensor Reference Number (note that this code may not necessarily match 
any of the codes associated with the observing or observed States Parties), 
"rrrr" is one of the codes, "OP AA ", "OF AA ", "TVLI", "TVFI", "IRLS", or 
"SAR A ", or additionally, "IRFI", to support the use of infrared frame-imaging 
devices and the caret character is used to represent a blank space, or other 
codes as described in applicable future decisions, and "ssss" is an unique 
reference four-digit number in the range 0000 to 9999 assigned by the State 
Party or group of States Parties that owns the sensor); 

(I) Sensor description as defined in Treaty Annex B, Appendix 1, paragraph 2, 
recorded as a fixed-width field pair, where the first value is the literal string, 
"SENSOR DESCRIPTION:", and the second value is a generated string of 
the form, "xxxxyy" (where "xxxx" is one of the following codes, "OP AA ", 
"OF AA ", "TV AA ", "IRLS", or "SAR A " as defined by the Treaty reference, or 
additionally, "IRFI", to support the use of infrared frame imaging devices and 
the caret character is used to represent a blank space, or other codes as 
described in applicable future decisions, and "yy" is one of the following 
codes, "BI", "BM", "BP", "BR", "TA", or "TD" as defined by the Treaty 
reference, or additionally, "HD", to support the use of digital media, such as 
DVD, solid state, and digital hard drive media, or other media codes as 
described in applicable future decisions); 

(J) Sensor configuration, as described in Treaty Annex B, Appendix 1, 

paragraph 3, but formatted as reported in the Notification Formats field 
SENSINSTAL, recorded as a fixed-width field pair, where the first value is 
the literal string, "SENSOR INSTALLATION:", and the second value is a 
generated string of the form, "aaa-b-c-dd" (where "aaa" is either "INT" or 
"POD", "b" is a number from "1" to "9" for internal installations or a letter 
"L", "R", or "C" for podded installations, "c" is a letter "V", "L", "R", or "F", 
and "dd" is two-digit number whose meaning depends upon the value of "c" - 
two-digit depression angle for a value of "V", "L", or "R", and two one-digit 
fan installation numbers for a value of "F" (the first number indicating the 
total number of sensors in the fan, and the second number indicating the 
individual sensor position in sequence from left to right relative to the 
direction of flight of the aircraft), and the hyphen-minus characters, are 
used as literal delimiters); 



(K) Focal length in millimetres, if applicable, or three blank spaces (0x20) if not 
applicable, recorded as a fixed-width field pair, where the first value is the 
literal string, "SENSOR FOCAL LENGTH:", and the second value is a 
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generated string of the form, "fff ' (where "fff ' is either a three-digit number in 
the range 001 to 999, or three blank spaces); 

(L) Total number of observation periods (as defined in Format 14) for the 

observation flight for which Image Data files related to the current sensor 
configuration are recorded on the current medium; this number is the total 
number of observation periods across all legs of all segments of the 
observation flight (as defined in Format 14) for which Image Data files are 
recorded on the current medium, recorded as a fixed-width field pair, where 
the first value is the literal string, ' 'NUMBEROFOB SERVATION 
PERIODS:", and the second value is a generated string of the form, 
"pppppppppp" (where "pppppppppp" is in the range 0000000001 to 
9979011999); 

(Note: The upper limit on the total number of observation periods (OP) is determined 
by multiplying the maximum number of flight segments (999), by the maximum number of 
legs per segment (999), by the maximum number of OPs per leg (9999), which can be 
recorded in this Media Annotation file format: 999 x 999 x 9999 = 997901 1999.) 

The following lines, (M) through (P), repeat as a set, for each observation period for 
which the current sensor configuration generated Image Data files which are recorded on the 
current medium. 

(M) Segment/leg/observation period record, as defined in Format 14, recorded as a 
fixed-width field pair, where the first value is the literal string, 
"SEG LEG OP RECORD:", and the second value is a generated string, 
formatted as a comma-separated list where the first element is the segment 
identifier ("aaa"), the second element is the leg identifier ("bbb"), the third 
element is the observation period identifier ("cccc"), the fourth element is the 
starting geographic co-ordinates for the observation period ("ddddddd 
eeeeeeee"), the fifth element is the ending geographic co-ordinates for the 
observation period ("ddddddd eeeeeeee"), the sixth element is the starting time 
(UTC) for the observation period ("CCYYMMDDhhmmss"), and the seventh 
element is the ending time (UTC) for the observation period 
("CCYYMMDDhhmmss"), (where the string element separator is a single 
comma character (0x2C), "aaa" is the flight segment in the range 001 to 999, 
"bbb" is the leg of the given flight segment in the range 001 to 999, "cccc" is 
the observation period for the leg of the given flight segment in the range 000 1 
to 9999, "ddddddd" and "eeeeeeee" are the latitude and longitude values, 
respectively, of the starting and ending geographic co-ordinates for the current 
observation period, "CCYY" is the year in the range 1991 to 9999, "MM" is 
the month in the range 01 to 12, "DD" is the day of the month in the range 01 
to 31, "hh" is the hour in the range 00 to 23, "mm" is the minute in the range 
00 to 59, and "ss" is the second in the range 00 to 59 (where the time stamp 
shall be truncated to the nearest second for OP start times and promoted to the 
nearest second for OP end times) for recording the starting and ending times 
associated with the current observation period); 

(Note that the 16-character format for the geographic co-ordinates recorded in 
line (M) shall be provided in either degrees-minutes-seconds (e.g. "4307 18N 0774032W") or 
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in decimal degrees (e.g., "43.122N 077.676W") where the hemisphere is indicated by the 
letters "E", "W", "N", or "S". In both cases, the latitude element is reported first and the 
longitude element is reported second.) 

(N) The total number of Image Data files, from the current instance of 
segment/leg/observation period, associated with the current sensor 
configuration, stored on this medium, recorded as a fixed-width field pair, 
where the first value is the literal string, "NUMBEROFIMAGEFILES 

THIS OP:", and the second value is a generated string of the form, 
"NNNNNNN" (where the value of "NNNNNNN" is in the range 0000001 to 
9999999); 

(O) Filename of the earliest-collected Image Data file written on this medium 

which is associated with the current observation period instance, recorded as a 
fixed-width field pair, where the first value is the literal string, 
"FIRST FILENAME IN OP:", and the second value is a string up to 
78 characters in length holding the name of the current file; 

(Note that although the actual file naming convention used by a State Party or group 
of States Parties is user-defined, it is highly recommended that the file naming convention 
provided in paragraph 3 of this section be used to promote the greatest level of 
interoperability within the Open Skies user community.) 

(P) Filename of the latest-collected Image Data file written on this medium which 
is associated with the current Observation Period instance, recorded as a 
fixed-width field pair, where the first value is the literal string, 
"LAST FILENAME IN OP:", and the second value is a string up to 
78 characters in length holding the name of the current file; note that when 
only one Image Data file on the medium is associated with the current instance 
of observation period that the name of the latest-collected file will be the same 
as that of the earliest-collected file; 

(Q) Total size in bytes of all of the Image Data files present on the medium, 

recorded as a fixed-width field pair, where the first value is the literal string, 
"TOTAL SIZE OF IMAGES IN BYTES:", and the second value is a 
generated string of the form, "NNNNNNNNNNNNNNNNNN" (where the 
value of "NNNNNNNNNNNNNNNNNN" is in the range 00000000000000 
0383 to 999999999999999999, or 000000000000000000 if only ICD files are 
present on the medium); 

(Note that the limit of this size field is designed for up to an exabyte of data minus 
one byte (1.0 EB - 1 byte). Here the term exabyte (EB) is used in the modern sense of 
1.0x1 0 18 bytes, and is not to be confused with the term exbibyte, which has replaced the more 
traditional binary value based on a power of 1024 (one exbibyte = 2 60 bytes = 
1,152,921,504,606,846,976 bytes). 

(R) The total number of ICD files located on the current exchange medium 
associated with Image Data files collected during the observation flight, 
recorded as a fixed-width field pair, where the first value is the literal string, 
"NUMBER OF ICD FILES:", and the second value is a generated string of 
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the form, "NN"; note that Image Data files from the observation flight do not 
have to reside on the same medium with the ICD files (where the value of 
"NN" is in the range 00 to 99) For OSDDEF 1.1, "NN" = 00; 

The following line, (S), repeats for each ICD file stored on the current medium 
associated with the observation flight, but only when the value of the preceding line, (R), is 
greater than "00"; if the value of the preceding line, (R), is "00", then the line, (S), is not 
present in the Media Annotation record of the observation flight on this medium. 
Subparagraphs (S) and (T) are only applicable to OSDDEF 1.2. 

(S) Filename of the current ICD file, recorded as a fixed-width field pair, where 
the first value is the literal string, "ICD_FILENAME:", and the second value 
is a string up to 78 characters in length holding the name of the current ICD 
file; 

The following line, (T), is present in the Media Annotation record only when the 
value of line, (R), is greater than "00"; if the value of line, (R), is "00", then the line, (T), is 
not present in the Media Annotation record of the observation flight on this medium. 

(T) Total size in bytes of all of the ICD files present on the medium, recorded as a 
fixed-width field pair, where the first value is the literal string, 
"TOTAL SIZE OF ICDS IN BYTES:", and the second value is a generated 
string of the form, "NNNNNNNNNN" (where the value of 
"NNNNNNNNNN" is in the range 0000000001 to 9999999999). 

Annex H, paragraph 1 provides some sample Media Annotation files. 

3. RECOMMENDED OSDDEF IMAGE FILE NAMING CONVENTION 

The following is a recommended convention for naming OSDDEF Image Data files 
on a direct access exchange medium. The filename is a continuous ASCII string, from 40 to 
52 characters in length, composed of: 

(A) The Open Skies flight reference number as updated by OSCC Decision 

No. 4/10 (7 characters, "OSyynnn", where the string "OS" is as written, "yy" 
is the last two digits of the calendar year of the flight, and "nnn" is a unique 
three-digit number that identifies the flight); 

(B) The sensor reference number, as reported in the SENSREFNUM field; altered 
such that any blank spaces that would normally appear in the population of the 
SENSREFNUM field are replaced with underscore characters to promote 
interoperability with computer operating systems which cannot tolerate blank 
spaces in file names (12 characters, "cc-rrrr-ssss", where "cc" is the Open 
Skies two-character country code or group code, "rrrr" is one of the codes, 
"OF_", "OP_", "TVLI", "TVFI", "IRLS", or "SAR ", or additionally, 
"IRFI", to support the use of infrared frame-imaging devices, and "ssss" is a 
nationally-assigned unique reference four-digit number in the range "0000" to 
"9999"); 
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(C) Image date and time in Co-ordinated Universal Time to the nearest second 
(15 characters, "CCYYMMDDhhmmsss", where "CCYY" is the four-digit 
year in the range 1991 to 9999, "MM" is the month in the range 01 to 12, 
"DD" is the day in the range 01 to 31, "hh" is the hour in the range 00 to 23, 
and "mm" is the minute in the range 00 to 59, and "sss" is the nearest tenth of 
a second in the range 000 to 599); 

(D) The image sequence number as defined by option (1) or option (2) below (2 to 
14 characters, beginning with an underscore character, "_n" to 
"_nnnnnnnnnnnnn", where the series of "n" characters represents a series of 
individual numeral characters, "0" through "9", forming an integer number of 
the desired length); 

(1) In the case of line-imaging devices, for each sensor reference number, 
the sequential file number of the image created in accordance with 
paragraph 4 of Decision Number Eight of the Treaty, based on 
temporal ordering of collection time, starting from the beginning of the 
mission; 

(2) In the case of frame-imaging devices, for each sensor reference 
number, the frame number of the image, starting from the beginning of 
the mission; 

(E) The OSDDEF file extension, which identifies the file as an Image Data file 
(4 characters, the literal string ".BIF"). 

The following are some example file names that can be created under the suggested 
naming convention: 

OS03567US-TVFI-30072003 1023 1449000_1 1 .BIF 
OS09003PL-IRLS-98762009063009 1 6 1 35_1 024.BIF 
OS11502RU-SAR-0001201105110712552 512.BIF 
OS13303UA-SAR_-1234201308241902458_0000000000001.BIF 
OS141 1 1LT-TVLI-5885201403220630220_0000000004096.BIF 
OS151 1 1DE-IRFI-5555201509130622009 45.BIF 

4. OSDDEF IMAGE FILE DEFINITION 

Specific information regarding the contents of OSDDEF-formatted files is provided in 
Annexes A through G. 

Field entries in the tables provided in Annexes A through E and Annex G are 
designated as being formatted as "alphanumeric" or "numeric" strings by the presence of the 
letter "A" or letter "N" following the field byte size entry in the SIZE columns of the tables. 
Fields where the string formatting is user-defined have been marked with the label 
"(User-defined)". 
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5 . OPEN SKIES INTERFACE CONTROL DOCUMENT FILE DEFINITION 

For OSDDEF 1.1 formatted files, Annexes C and E are the Interface Control 
Documents (ICD). 

This decision does not provide an OSDDEF-based logical format for an Open Skies 
Interface Control Document (ICD). The sole requirement applied to the generation of Open 
Skies ICD files is that any such file should be capable of being read by any commercially 
available text editing software application (e.g., Notepad, WordPad, etc.). 

SECTION VII. EXAMPLE DATA 

Annex H provides examples of the structure and contents of OSDDEF Media 
Annotation files. 

Annex I provides examples of File Headers and Image Segment Subheaders for 
various sensors and a notional example of a user-defined TRE and an associated OSDDEF 
1.2 ICD file describing the user-defined TRE. 

Annex J provides a current listing of the Open Skies country codes and group codes 
that should be used when populating OSDDEF files. 

This decision shall enter into force immediately. It shall remain in force until 
31 December 2020. 

Decided in Vienna, in the Open Skies Consultative Commission, on 
16 September 2013, in each of the six languages specified in Article XIX of the Treaty on 
Open Skies, all texts being equally authentic. 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT FILE HEADER 



Table A. 1 provides the population rules for an OSDDEF-compliant File Header. Field 
value contents are provided based on the current Decisions but may be altered by future 
decisions. 



Table A.1: OSDDEF FILE HEADER 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


FHDR 


OSDE 


4 A 


BIIF Profde Name 


R 


FVER 


01.10 (for OSDDEF 1.1) 
01.20 (for OSDDEF 1.2) 


5 A 


Version of BIIF Profde 


R 


CLEVEL 


00 


2N 


Profde Complexity Level 


R 


STYPE 


BF01 


4A 


Standard Type 


R 


OSTAID 


OPEN SKIES 


10 A 


Originating Source 


R 


FDT 


CCYYMMDDhhmmss 

(where "CCYY" is the 
4-digit year in the range 
1991 to 9999, "MM" is the 
month in the range 01 to 
12, "DD" is the day in the 
range 01 to31,"hh" is the 
hour in the range 00 to 23, 
"mm" is the minute in the 
range 00 to 59, and "ss" is 
the second in the range 00 
to 59) 


14 N 


File Creation Date and Time, 
in Co-ordinated Universal 
Time 


R 


FTITLE 


OPEN SKIES DIGITAL 
DATA EXCHANGE 
MEDIA ANNOTATION 

or 

OPEN SKIES DIGITAL 
DATA EXCHANGE 
IMAGE DATA 

(followed by blank spaces 
to fill all 80 characters) 


80 A 


File Title 


R 


FSEC 


FOR OPEN SKIES 
PURPOSES ONLY 

(followed by blank spaces 
to fill all 1 67 characters) 


167 A 


File Security Marking, per 
profde-specific security 
parameters 


R 


FSCOP 


00000 


5N 


File Copy Number 


R 


FSCPYS 


00000 


5N 


File Total Number of Copies 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


ENCRYP 


0 


1 N 


Encryption Code 
(0 = Not Encrypted) 


R 


OID 


Name of the State Party or 
group of States Parties 
responsible for third party 
requests 

(followed by blank spaces 
to fill all 45 characters) 


45 A 


Originator's Identification 

(Note: The codes provided in 
Annex J shall be used to 
populate this field.) 


R 


FL 


000000000388 to 
999999999999 


12 N 


Length of the entire file, 
including the File Header, all 
Segment Subheaders, and all 
data, in bytes 


R 


HL 


000388 to 999999 


6N 


Length of the File Header, in 
bytes 


R 


NUMI 


001 (for Image Data files) 

000 (for Media Annotation 
files) 


3N 


Number of Image Segments 
in the file 


R 


Image Segments Loop; Loop runs from nnn = 001 to NUMI 


LISHnnn 


000439 to 999999 


6N 


Length of the nnn" 1 Image 
Segment Subheader, in bytes 


C 


LInnn 


0000000001 to 

9999999999 


10N 


Length of the nnn" 1 Image 
Segment Data, in bytes 


C 


End of Image Segments Loop 


NUMS 


000 


3N 


Number of Symbol/Graphic 
Segments in the file 


R 


NUMX 


000 


3N 


Reserved for future use 


R 


NUMT 


001 (for OSDDEF 1.1 
Image Data files) 

000 to 999 (for OSDDEF 
1 .2 Image Data files) 

001 to 999 (for OSDDEF 
1.1 and OSDDEF 1.2 
Media Annotation files) 


3N 


Number of Text Segments in 
the file 


R 


Text Segments Loop; Loop runs from nnn = 001 to NUMT 


LTSHnnn 


0282 to 9999 


4N 


Length of the nnn" 1 Text 
Segment Subheader, in bytes 


C 


LTnnn 


00001 to 99999 


5N 


Length of the nnn" 1 Text 
Segment Data, in bytes 


C 


End of Text Segments Loop. 


NUMDES 


000 to 999 (for Image Data 
files) 

000 (for Media Annotation 
files) 


3N 


Number of Data Extension 
Segments in the file 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


Data Extension Segments Loop; Loop runs from nnn = 001 to NUMDES 


LDSHnnn 


0209 


4N 


Length of the nnn th Data 
Extension Segment 
Subheader, in bytes 

(Note: When the DES is a 
TREOVERFLOW DES, the 
subheader size is set to 0209 
bytes.) 


C 


LDnnn 


000000001 to 999999999 


9N 


Length of the nnn th Data 
Extension Segment Data, in 
bytes 


C 


End of Data Extension Segments Loop 


NUMRES 


000 


3N 


Number of Reserved 
Extension Segments in the file 


R 


UDHDL 


00000, 00003 or 
00015 to 99999 


5N 


User-Defined Header Data 
Length, in bytes 


R 


The following two fields only exist if the value of the UDHDL field is greater than or equal to 00003 


UDHOFL 


000 

(if overflow did not occur) 
001 to 999 

(if overflow did occur) 


3N 


User-Defined Header Data 
Overflow indicator; value 
reported is the positional 
number of the DES in the file 
which the User-Defined 
Header Data (UDHD) field 
overflowed to 

(Field is present only if 
UDHDL + 00000) 


C 


UDHD 


A series of User-Defined 
TRE 


UDHDL-3 
(User-defined) 


User-Defined Header Data 

(Field is present only if 
UDHDL > 00003) 


C 


End of the UDHDL conditional fields 


XHDL 


00000 


5N 


Extended Header Data 
Length, in bytes 


R 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT IMAGE 

SEGMENT SUBHEADER 



Table B.l provides the population rules for an OSDDEF-compliant Image Segment 
Subheader. Note that in addition to the information provided in Section VI, paragraph 4, 
fields in Table B.l containing binary integer data have been marked with the label "(Series of 
n-bit integers)", where "n" represents some whole number. Field value contents are provided 
based on the current decisions but may be altered by future decisions. OSDDEF 1.1 files may 
only use the user-defined SAR Information Parameter TRE defined in Annex C, paragraph 2, 
of this decision. Other user-defined formats and information in the following table are only 
allowed in OSDDEF 1.2. Any user-defined formats, information, or look-up tables must be 
fully and unambiguously defined in an accompanying Open Skies ICD file. 



Table B.l: OSDDEF IMAGE SEGMENT SUBHEADER 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


IM 


IM 


2 A 


Image Segment Subheader 
Identifier 


R 


IID 


0000000000 to 

9999999999 

(Frame Number or Line 

Counter) 


10N 


Image Identifier (Frame or 
line number increasing 
monotonically) 


R 


IDATIM 


CCYYMMDDhhmmss 

(where "CCYY" is the 
4-digit year in the range 
1991 to 9999, "MM" is the 
month in the range 01 to 
12, "DD" is the day in the 
range 01 to 31, "hh" is the 
hour in the range 00 to 23, 
"mm" is the minute in the 
range 00 to 59, and "ss" is 
the second in the range 00 
to 59) 


14 N 


Image Acquisition Date and 
Time, in Co-ordinated 
Universal Time 


R 


IINFO 


all blank spaces or 

User-defined Image 
Information 

(followed by blank spaces 
to fill all 97 characters) 


97 A 


Image Information 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


ISCSEC 


FOR OPEN SKIES 
PURPOSES ONLY 

(followed by blank spaces 
to fill all 1 67 characters) 


167 A 


Image Segment Security 
Marking, per profile-specific 
security parameters 


R 


ENCRYP 


0 


1 N 


Encryption Code 
(0 = Not encrypted) 


R 


ISORCE 


cc-rrrr-ssss 

(where "cc" is the 
2-character country or 
group code, "rrrr" is one of 
the codes: OF AA , OP AA , 
TVLI, TVFI, IRLS, IRFI, 
or SAR A where the caret 
character, " A ", indicates a 
single blank space, and 
"ssss" is a 

nationally-assigned unique 
reference 4-digit number in 
the range 0000 to 9999) 


42 A 


Image Source 

(Note: For OSDDEF this 
field holds the Sensor 
Reference Number, 
SENSREFNUM.) 


R 


NROWS 


00000001 to 99999999 


8N 


Number of Rows in the 
Image 


R 


NCOLS 


00000001 to 99999999 


8N 


Number of Columns in the 
Image 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


PVTYPE 


INT 

SI 

R 

C 

(followed by blank spaces 
to fill all three characters) 


3 A 


Pixel Value Type 
In General: 

"INT" is unsigned integer; 

"SI" is a signed integer in 2's 
complement format; 

"R" is a 32-bit real 
floating-point value in IEEE 
754 format; 

"C" is a 64-bit complex 
value consisting of an 
ordered pair of 32-bit IEEE 
754-formatted floating-point 
values, the first representing 
the real part of the complex 
number and the second 
representing the imaginary 
part; 

Multi-byte values shall be 
coded in order of 
significance, beginning with 
the most significant byte and 
ending with the least 
significant byte. 


R 


IREP 


MONO 
RGB 

RGB/LUT 
MULTI 

(followed by blank spaces 
to fill all eight characters) 


8 A 


Image Representation 

MONO indicates a 
single-band (monochromatic) 
image. 

RGB indicates a three-band 
image representing a red, 
green, and blue spectral 
collection. 

RGB/LUT means a 
single-band image whose 
values are indices into a 
3-colour (RGB) look-up 
table (LUT) provided 
elsewhere in the subheader. 

MULTI indicates any 
multi-band file. Note that an 
RGB image could also be 
designated as a MULTI 
image. 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


ICAT 


VIS 
IR 
MS 
SAR 

(followed by blank spaces 
to fill all eight characters) 


8 A 


Image Category 

VIS indicates [single band] 
visible imagery. 

IR indicates single -band 
infrared imagery. 

MS indicates multispectral 
(multi-band) visible and/or 
infrared imagery. 

SAR indicates synthetic 
aperture radar (SAR) 
imagery. 


R 


ABPP 


01 to 96 


2N 


Actual 

Bits-per-Pixel-per-Band 


R 


PJUST 


RorL 


1 A 


Pixel Justification 

(R = right-justification, 

L = left-justification) 

When ABPP is unequal to 
NBPP, indicates whether the 
most significant bits are left 
justified (L) or right justified 
(R). 


R 


ICORDS 


A single blank space 
(0x20) 


1 A 


Image Co-ordinate System 
(blank space = none) 


R 


N1COM 


0 


1 N 


Number of Image Comments 


R 


Image Comments Loop; Loop runs from n = . 


I to NICOM 


ICOMn 


User-defined free text. 


80 A 


n th Image Comment 


C 


End of Image Comments Loop 


IC 


NC 


2 A 


Image Compression 
(NC = No Compression) 


R 


NBANDS 


1, 3, or 4 


1 N 


Number of Bands in the 
Image 

(Note: The range of this field 
is 0 to 9; see the XBANDS 
field for more information.) 


R 


The following field only exists if the value of the NBANDS fiek 


1 is equal to zero 


XBANDS 


00010 to 99999 


5N 


Number of Multi-Spectral 
Bands 

When the NBANDS field 
contains a value of 0, this 
field shall contain the true 
number of bands in the 
image. 


C 


End of the NBANDS conditional field 


Bands Loop; Loop runs from n = 1 to maximum(NBANDS, XBANDS) 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


IREPBANDn 


R (for red display channel) 

G (for green display 
channel) 

B (for blue display 
channel) 

or two blank spaces (no 
display channel designated) 

(followed by blank spaces 
to fill the two characters) 


2 A 


Representation of the n" 1 
Band 

The values R, G, and B are 
only allowed when IREP = 
RGB or MULTI, and the 
number of bands in the 
image is greater than or equal 
to three. Two blank spaces 
are used for any band not 
designated for default display 
to either the red, green, or 
blue channel of the display 
device. 

The bands assigned to the 
red, green, and blue channels 
for default display can be 
recorded in any order in the 
Image segment, as long as 
their corresponding 
IREPBANDn and 
ISUBCATn fields are 
properly populated to 
identify the default display 
channel and band centre 
wavelength. 

For images with fewer than 
three bands, the only valid 
value is two blank spaces 
(this includes imagery with 
an IREP = RGB/LUT as well 
as MONO). 


C 


ISUBCATn 


Centre Wavelength in one 
of the formats: 

00.000 to 99.999 

000.00 to 999.99 


6A 


Subcategory of the n th Band. 
Holds the centre wavelength 
of then" 1 Band. 

Units of centimetres for SAR 
imagery (ICAT = "SAR"), 
otherwise units of 
micrometers. 


C 


IFCn 


N or User-defined 


1 A 


Image Filter Condition of the 
n th Band 


c 


IMFLTn 


three blank spaces or User- 
defined 


3 A 


Standard Image Filter Code 
for the n' h Band 


c 


NLUTSn 


0to4 


1 N 


Number of Look-Up Tables 
(LUT) associated with the n ,h 
Band 


c 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


The following fields only exist if the value of the NLUTSn field is greater than zero 


NELUTn 


00001 to 65536 


5N 


Number of Entries in Each 
LUT for the n th Band 

(Note: This field is present 
only when NLUTSn > 0.) 


C 


LUT Entries Loop; Loop runs from m = 1 to NLUTSn 


LUTDnm 


Look-Up Table (LUT) 
values for the m th LUT of 
the n th Band recorded as a 
single data block of 
NELUTn integers, where 
the individual integers are 
NBPP bits in size. 


NELUTn 
(Series of 
NBPP-Bit 
Integers) 


LUT Entries for the m th LUT 
associated with the n th Band 

(Note: This field is present 
only when NLUTSn > 0 and 
the value of PVTYPE = 
INT.) 


C 


End of LUT Entries Loop 


End of the NLUTSn conditional fields 


End of Bands Loop 


ISYNC 


0 


1 N 


Image Synchronization Code 

0 indicates that there are no 
synchronization codes in the 
image data. 


R 


IMODE 


B 
p 

S 


1 A 


Image Mode 

B = Band Interleaved 
(required value for all 
single-band images) 

P = Pixel Interleaved 

S = Band Sequential 


R 


NBPR 


0001 to 9999 


4N 


Number of Blocks (tiles) per 
Row 


R 


NBPC 


0001 to 9999 


4N 


Number of Blocks (tiles) per 
Column 


R 


NPPBH 


0001 to 9999 


4N 


Number of Pixels per Block 
Horizontal 

Any combination of NBPR 
and NPPBH such that 
NBPR*NPPBH > NCOLS is 
acceptable. 


R 


NPPBV 


0001 to 9999 


4N 


Number of Pixels per Block 
Vertical 

Any combination of NBPC 
and NPPBV such that 
NBPC*NPPBV > NROWS 
is acceptable. 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


NBPP 


01 to 96 


2N 


Number of Bits per Pixel per 
Band (bpppb) 

(Note: NBPP > ABPP.) 


R 


IDLVL 


001 


3N 


Image Display Level 


R 


IALVL 


000 


3N 


Image Attachment Level 


R 


ILOC 


0000000000 


10N 


Image Location 


R 


IMAG 


1.00 


4A 


Image Magnification 


R 


UDIDL 


00000, 00003 or 
00015 to 99999 


5N 


User-Defined Image 
Subheader Data Length, in 
bytes 


R 


The following two fields only exist if the value of the UDIDL field is greater than or equal to 00003 


UDOFL 


000 

(if overflow did not occur) 
001 to 999 

(if overflow did occur) 


3N 


User-Defined Image 
Subheader Data Overflow 
indicator; value reported is 
the positional number of the 
DES in the file which the 
User-Defined Image 
Subheader Data (UDID) field 
overflowed to 

(Field is present only if 
UDIDL + 00000) 


C 


UDID 


A series of User-Defined 
TRE 


UDIDL-3 
(User-defined) 


User-Defined Image 
Subheader Data 

(Field is present only if 
UDIDL > 00003) 


C 


End of the UDIDL conditional fields. 


IXSHDL 


00000, 00003 or 
00015 to 99999 


5N 


Extended Image Subheader 
Data Length, in bytes 


R 


The following two fields only exist if the value of the IXSHDL field is greater than or equal to 00003 


IXSOFL 


000 

(if overflow did not occur) 
001 to 999 

(if overflow did occur) 


3N 


Extended Image Subheader 
Data Overflow indicator; 
value reported is the 
positional number of the 
DES in the file which the 
Extended Image Subheader 
Data (IXSHD) field 
overflowed to 

(Field is present only if 
IXSHDL + 00000) 


C 


IXSHD 


A series of User-Defined 
TRE 


IXSHDL-3 
(User-defined) 


Extended Image Subheader 
Data 

(Field is present only if 
IXSHDL > 00003) 


C 


End of the IXSHDL conditional fields. 
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OPEN SKIES TAGGED RECORD EXTENSIONS 



The following discussion defines the general format for a Tagged Record Extension 
(TRE) for use with OSDDEF files. The first paragraph of this annex deals with general rules 
regarding TRE creation, and the second paragraph defines an Open Skies TRE template for 
recording SAR Information Parameters. 

OSDDEF 1.1 files may only use the user-defined SAR Information Parameter TRE 
defined in Annex C, paragraph 2, of this decision. Other user-defined formats and 
information in the following table are only allowed in OSDDEF 1.2. Any user-defined 
formats or information must be fully and unambiguously defined in an accompanying 
Open Skies ICD file. 

1 . USER-DEFINED TAGGED RECORD EXTENSIONS 

Table C.l describes the basic structure of a user-defined Tagged Record Extension. 
User-defined Tagged Record Extensions created by a State Party, or group of States Parties, 
can be recorded in the following fields of an OSDDEF Image Data file, or an associated 
TRE OVERFLOW DES: UDHD, UDID, IXSHD, or TXSHD. Fields where the data 
formatting is user-defined have been marked with the label "(User-defined)", however, any 
user-defined field in the body of a TREDATA field must be either an "alphanumeric" or a 
"numeric" string value, in order to meet the requirements for annotation as defined by the 
decisions to the Treaty on Open Skies. 



Table C.l: OPEN SKIES USER-DEFINED TAGGED RECORD EXTENSION 
FORMAT 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


TRETAG 


User-defined identifier 
consisting of some 
combination of capital 
letters, (A to Z), and 
numerals (0 to 9) 

Some notional examples: 

DKTRE9 

ABC123 

MY 1 TAG 


6A 


Unique Tagged Record 
Extension Identifier 

(Note: The data provider should 
ensure that the chosen identifier 
does not duplicate identifiers 
used by other data providers. 
Informal coordination of 
identifiers within the IWGS is 
strongly encouraged. Including 
two-character country codes of 
the originator of the TRE will 
help avoid inadvertent 
duplication of TRET AGs.) 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


TREL 


00001 to 99985 


5N 


Total Length of the Tagged 
Record Extension TREDATA 
field 

(Note: This length does not 
include the 1 1 bytes used to 
record the TRET AG and TREL 
fields.) 


R 


TREDATA 


User-defined data fields 


TREL 
(User-defined) 


User-Defined Data Fields 


R 



2. OPEN SKIES TAGGED RECORD EXTENSION TEMPLATE FOR SAR 
INFORMATION PARAMETERS 



Table C.2 describes the basic structure of the Tagged Record Extension template for 
use in reporting SAR Information Parameters known as "ccSARn". The actual name used to 
identify a State Parly's, or group of States Parties', implementation of this TRE is determined 
as follows: "cc" is the country or group code of the data provider, followed by the literal 
string "SAR", followed by a single digit version identifier. For example, the first Canadian 
implementation of this ccSARn TRE might be identified as "CASAR0". When used in an 
Image Data file, the ccSARn TRE may be placed in either the UDID or IXSHD fields of the 
Image Segment Subheader. 

Table C.2: "ccSARn" TRE TEMPLATE FORMAT FOR SAR INFORMATION 
PARAMETERS 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


TRETAG 


ccSARn 

(where "cc" is the 
country or group 
code of the data 
provider and "n" is a 
single digit provided 
for use in version 
control) 


6 A 


Unique Tagged Record 
Extension Identifier for 
Reporting SAR Information 
Parameters 


R 


TREL 


00080 (for OSDDEF 
1.1) 

00080 to 99985 (for 
OSDDEF 1.2) 


5 N 


Total Length of the Tagged 
Record Extension 

(Note: This length does not 
include the 1 1 bytes used to 
record the TRETAG and 
TREL fields.) 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


Start of TRE Data Fields 


SARTYP 


LINEAR FM CHIRP 
(for a straight-flying 
SAR using a linear 
FM chirp emitted 
pulse) 

(followed by blank 
spaces to fill all 
twenty characters) 


20 A 


Type of Synthetic Aperture 
Radar (SAR) 


R 


SARRT 


R (for range to first 
sample) 

T (for time to first 
sample) 


1 A 


Indicator of Range or Time 
to First Sample 


R 


SARSLANTMN 


000000.0 to 
999999.9 


8 N 


Range or Time to First 
Sample 

If SARRT = R, then the units 
associated with this value are 
metres. 

If SARRT = T, then the units 
associated with this value are 
microseconds. 


R 


SARFW 


F (for SAR operating 
frequency) 

W (for SAR 

operating 

wavelength) 


1 A 


Indicator of SAR Operating 
Frequency or Wavelength 


R 


SAROPFREQ 


00000.00 to 
99999.99 


8N 


Emitted Pulse Carrier 
Frequency or Wavelength 

If SARFW = F, then this 
field contains the emitted 
pulse carrier frequency in 
megahertz (MHz) to the 
nearest one-tenth megahertz. 

If SARFW = W, then this 
field contains the emitted 
pulse wavelength in 
centimetres. 


R 


SARBANDTX 


000.00 to 999.99 


6N 


Emitted Pulse Bandwidth in 
megahertz (MHz) 


R 


SARDUR 


00.0000 to 99.9999 


7N 


Emitted Pulse Duration, in 
microseconds 


R 


SARNP 


N (for pulses per 
metre of flight path) 
P (for pulse 
repetition frequency 
in Hz) 


1 A 


Indicator of Pulses Per Metre 
or Pulse Repetition 
Frequency 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


SARPULSES 


0000.000 to 
9999.999 


8N 


Emitted Number of Pulses 
Per Metre of Flight Path or 
Pulse Repetition Frequency 

If SARNP = N, then this 
field contains the number of 
pulses per metre of flight 
path. 

If SARNP = P, then this field 
contains the pulse repetition 
frequency in Hertz (Hz). 


R 


SARVEL 


000.0000 to 
999.9999 


8N 


Along-Track Platform 
Velocity, in metres per 
second 


R 


SARAAB 


0.0000 to 9.9999 


6N 


Azimuthal Antenna 
Beamwidth, in radians 


R 


SARRANNUM 


0.0000 to 9.9999 


6N 


Number of Range Samples 
Generated per Metre of Slant 
Range 


R 


Start of User-Defined SAR-Specific Data Fields (The following fields exist only ifTREL > 80) 


SARUDDATA 


User-defined 


TREL-80 
(User-defined) 


User-Defined SAR-Specific 
Data 

(Note: This field is only 
allowed in OSDDEF 1.2 
files.) 


C 


End of User-Defined SAR-Specific Data Fields 


End of TRE Data Fields 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT TEXT 
SEGMENT SUBHEADER 



The following discussion defines the general format for a Text Segment Subheader 
for use with OSDDEF files. Field value contents are provided based on the current Decisions 
but may be altered by future decisions. 

1 . TEXT SEGMENT SUBHEADER DEFINITION 

Table D. 1 provides the population rules for an OSDDEF-compliant Text Segment 
Subheader. 



Table D.l: OSDDEF TEXT SEGMENT SUBHEADER 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


TE 


TE 


2 A 


Text Segment 
Subheader Identifier 


R 


TEXTID 


ANNOTATION (for Image 
Annotation Text Segments) 

MEDIA HDR (for Media 
Annotation Text Segments) 

User-defined (for Text Segments 
containing non-image information; 
for use in OSDDEF 1.2 files only) 


10N 


Text Identifier 


R 


TXTDT 


CCYYMMDDhhmmss 

(where "CCYY" is the 4-digit year 
in the range 1991 to 9999, "MM" is 
the month in the range 01 to 12, 
"DD" is the day in the range 01 to 
3 1 , "hh" is the hour in the range 00 
to 23, "mm" is the minute in the 
range 00 to 59, and "ss" is the 
second in the range 00 to 59) 


14 N 


File Creation Date and 
Time, in Co-ordinated 
Universal Time 

(Note: In the OSDDEF 
Profile, this time stamp 
reflects the time of file 
creation, and should 
therefore be equal to the 
FDT field in the Main 
Header.) 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


TXTITL 


OPEN SKIES MEDIA 
ANNOTATION (for Media 
Annotation Text Segments) 

OPEN SKIES IMAGE 
ANNOTATION (for Image Data 
file annotation Text Segments) 

User-defined (for Text Segments 
containing non-image information; 
for use in OSDDEF 1.2 files only) 

(followed by blank spaces to fill all 
80 characters) 


80 A 


Text Title 


R 


TSSEC 


FOR OPEN SKIES PURPOSES 
ONLY 

(followed by blank spaces to fill all 
167 characters) 


167 A 


Text Segment Security 
Marking, per 
profile-specific security 
parameters 


R 


ENCRYP 


0 


1 N 


Encryption Code 
(0 = Not Encrypted) 


R 


TXTFMT 


STA 


3 A 


Text Format Identifier. 


R 


TXSHDL 


00000, 00003 or 
00015 to 09717 


5N 


Extended Text 
Subheader Data Length, 
in bytes 


R 


The following two fields only exist if the value of the TXSHDL field is greater than or equal to 00003 


TXSOFL 


000 

(if overflow did not occur) 
001 to 999 

(if overflow did occur) 


3N 


Extended Text 
Subheader Data 
Overflow Indicator; 
value reported is the 
positional number of the 
DES in the file which 
the Extended Text 
Subheader Data 
(TXSHD) field 
overflowed to 

(Field is present only if 
TXSHDL + 00000) 


C 


TXSHD 


A series of User-Defined TRE 


TXSHDL-3 
(User-defined) 


Extended Text 
Subheader Data 

(Field is present only if 
TXSHDL > 00003) 


C 


End of the TXSHDL conditional fields 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT VERSION 1.1 
TEXT DATA FORMAT FOR TREATY-REQUIRED IMAGE 
ANNOTATION INFORMATION 



Table E.l provides the population rules for an OSDDEF 1.1 compliant Text Segment 
containing required image annotation information data. The Text Segment Subheader shall be 
populated in accordance with the provisions of Annex D of this decision. 

Treaty-required image annotation information, reported in a Text Segment according 
to the provisions of Table E.l, shall be formatted according to the BCS-A character subset of 
the ASCII character encoding standard. Field value contents are provided based on Decision 
No. 4/10, the decision on annotation of data collected during an observation period, and by 
future decisions. User-defined fields are not permitted in OSDDEF 1.1. States Parties wishing 
to include optional data annotation are required to use OSDDEF 1.2 construct identified in 
Annex F of this decision. 



Table E.l: OSDDEF 1.1 TREATY-REQUIRED IMAGE ANNOTATION TEXT DATA 
FORMAT 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


OSFLT 


OSyynnn 

(where the first two 
characters are the literal 
string "OS", "yy" is the 
last two digits of the 
calendar year of the 
flight, and "nnn" is a 
unique three-digit 
number that identifies the 
flight) 


7A 


Observation Flight Reference 
Number, as Updated by OSCC 
Decision No. 4/10 


R 


OSDAT 


CCYYMMDD 

(where "CCYY" is the 
four-digit year in the 
range 1991 to 9999, 
"MM" is the two-digit 
month in the range 01 to 
12, and "DD" is the 
two-digit day in the range 
01 to 31) 


8N 


Observation Flight Date, in 
Co-ordinated Universal Time 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


OSSNSR 


xxxxyy 


6 A 


Sensor Description Information, 


R 








as defined in Treaty Annex B, 






(where "xxxx" is one of 




Appendix 1 , paragraph 2 






the following codes, 










"OP", "OF", "TV", 




(Note: An additional media 






"IRLS", or "SAR", or 




code, "HD", has been added to 






additionally, "IRFI" to 




this decision to support the use 






handle infrared frame 




of digital media such as DVD, 






imaging devices, 




solid state, and digital hard drive 






followed by blank spaces 




media.) 






to fill all four characters, 










and "yy" is one of the 










following codes, "BI", 










BM , "BP , BR , 










"TA", "TD", or "HD") 








SENSINSTAL 


aaa-b-c-dd 


10 A 


Sensor Installation Number 


R 








Code, based on the sensor 






(where 




installation number used in 






"aaa" is "INT" or 




Open Skies Notification Formats 






"POD", 




4, 5, and 6 






"b" is a number from "1" 




Installation Codes ("aaa"): 






to "9" indicating relative 




INT = internal sensor 






position from nose to tail 




installation 






for internal installations 




POD = podded sensor 






or the letter "L", "R", or 




installation 






"C" for podded 










installations, 




Pod-based Position Codes ("b"): 










L = pod mounted under left 






"c" is the letter "V", "L", 




wing 






"R", or "F", and 




R = pod mounted under right 










wing 






"dd" is a two-digit 




C = pod mounted on aircraft 






number whose meaning 




centre-line 






depends upon the value 










of "c" - two-digit 




Installation Type Codes ("c"): 






depression angle in 




V = vertical installation 






integer degrees for a 




L = left-looking installation 






value of "V", "L", or 




R = right-looking installation 






"R", and two one-digit 




F = Fan installation (2 or more 






fan installation codes for 




sensors) 






a value of "F", the total 










number of sensors 










followed by the 










individual sensor number, 










in sequence from left to 










right, relative to the 










direction of flight) 








OSFCLL 


000 to 999 


3N 


Focal Length, in millimetres (If 


R 








the focal length is not 










applicable, then OSFCLL = 000) 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


OSDTG 


CCYYMMDDhhmmsss 

(where "CCYY" is the 
4-digit year in the range 
1991 to 9999, "MM" is 
the month in the range 01 
to 12, "DD" is the day in 
the range 01 to 31, "hh" 
is the hour in the range 
00 to 23, "mm" is the 
minute in the range 00 to 
59, and "sss" is the 
second to the nearest 
tenth of a second in the 
range 000 to 599) 


15 N 


Image Acquisition Date and 
Time, in Co-ordinated Universal 
Time (This field contains the 
date and time that the data was 
collected to the nearest tenth of a 
second.) 


R 


OSHAGL 


xxxxxy 

(where "xxxxx" is an 
integer in the range 
00000 to 99999 and "y" 
is either F for feet or M 
for metres.) 


6A 


Average Height above Ground 
Level of the Observation 
Aircraft, in either feet or metres. 


R 


OSLOC 


dd.dddd(N or S) 
ddd.dddd(E or W) 

or 

dd mmss(N or S) ddd 
mmss(E or W) 


18 A 


Aircraft Location (This field 
contains the latitude and 
longitude of the position of the 
observation aircraft in decimal 
degrees to the nearest 
ten-thousandth of a degree or in 
degrees, minutes and seconds to 
the nearest second.) 


R 


OSHDG 


000.0 to 359.9 


5N 


True Heading of the Observation 
Aircraft, in degrees to the 
nearest tenth of a degree 


R 


OSSCAN 


000 to 359 


3N 


Scan Angle of the Sensor, in 
degrees to the nearest degree 

(Note: If the first four characters 
of the OSSNSR = "SAR", then 
OSSCAN = 000.) 


R 


OSLDA 


00 to 90 


2N 


Look Down Angle to the 
Nearest Point of the Swath 
Width, in degrees, to the nearest 
degree, measured from the 
vertical 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSLDA = 00.) 


R 



-4- OSCC.DEC/7/13 
16 September 2013 
Annex E 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


OSNEAR 


00 to 99 


2N 


Ground Distance to the Nearest 
Point of the Swath Width, in 
kilometres to the nearest 
kilometre 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSNEAR = 00.) 


R 


OSSWTH 


000 to 999 


3N 


Swath Width, measured in units 
of kilometres to the nearest 
kilometre 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSSWTH = 000.) 


R 


OSPOL 


HH 
HV 
VH 
VV 

or 2 blank spaces (0x20) 


2 A 


SAR Polarizations (Valid entries 
are HH, HV, VH, and VV) 

(Note: If the first four characters 
of the OSSNSR^ "SAR", then 
OSPOL = two blank spaces.) 


R 


OSSPD 


xxxyy 

(where "xxx" is an 
integer in the range 000 
to 999 and "yy" is NM 
for nautical miles per 
hour or KM for 
kilometres per hour.) 


5 A 


Ground Speed of the 
Observation Aircraft (The units 
associated with this value are 
either nautical miles per hour or 
kilometres per hour) 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSSPD = 000NM or 000KM, or 
optionally, the ground speed of 
the observation aircraft.) 


R 


OSDRFT 


xx. xy 

(where "xx.x" is the drift 
angle in the range 00.0 to 
90.0 and "y" is L for drift 
to the left or R for drift to 
the right) 


5 A 


Drift Angle of the Observation 
Aircraft, in degrees to the 
nearest tenth of a degree (The 
direction of the drift is either to 
the left or to the right relative to 
the flight path of the observation 
aircraft) 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSDRFT = 00.0L or 00.0R, or 
optionally, the drift angle of the 
observation aircraft.) 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


OSPTCH 


xx.xy 

(where "xx.x" is the pitch 
angle in the range 00.0 to 
90.0 and "y" is U for 
upwards pitch or D for 
downwards pitch) 


5 A 


Pitch Angle of the Observation 
Aircraft, in degrees to the 
nearest tenth of a degree (The 
direction of the pitch is either up 
or down relative to the 
horizontal) 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSPTCH = 00.0U or 00.0D, or 
optionally, the pitch angle of the 
observation aircraft.) 


R 


OSROLL 


xx.xy 

(where "xx.x" is the roll 
angle in the range 00.0 to 
90.0 and "y" is L for roll 
to the left or R for roll to 
the right) 


5 A 


Roll Angle of the Observation 
Aircraft, in degrees to the 
nearest tenth of a degree (The 
direction of the roll is either to 
the left or to the right relative to 
the centreline of the observation 
aircraft when looking forward 
out the nose of the aircraft.) 

(Note: If the first four characters 
of the OSSNSR + "SAR", then 
OSROLL = 00.0L or 00.0R, or 
optionally, the roll angle of the 
observation aircraft.) 


R 


FOCALRATIO 


000.1 to 999.9 

(for applicable sensors) 

000.0 (if not applicable or 
unavailable) 


5N 


Focal Ratio (The focal ratio is 
defined as the ratio of the focal 
length to the diameter of the 
entrance pupil of the lens, or 
f-number.) 

Not applicable to SAR. 

If not applicable or not available 
default is 000.0. 


R 


EXPOSURE 


00.00001 to 99.99999 
(for applicable sensors) 

00.00000 (if not 
applicable or unavailable) 


8N 


Exposure Time, in seconds 

Not applicable to SAR. 

If not applicable or not 
available, default is 00.00000. 


R 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT VERSION 1.2 
DATA FORMATS FOR ANNOTATION INFORMATION 



In the OSDDEF 1.2 version of the Open Skies logical format for digital data 
exchange, the exchange of non-image data of any kind is accomplished through the use of 
user-defined Text Segments and/or Tagged Record Extensions; even Treaty-required 
annotation information is provided in one of these two user-defined constructs. The choice to 
record certain items of annotation information in a Text Segment or a TRE is at the discretion 
of the data provider. Whatever the data provider decides to do, the annotation information 
written in the OSDDEF 1.2 Image Data file must be fully and unambiguously described in an 
accompanying Open Skies ICD file. 

1 . TEXT SEGMENT DATA AND TAGGED RECORD EXTENSION POPULATION 

Any annotation data written in Text Segments or Tagged Record Extensions shall be 
written in a fixed-width field pair format, as described in paragraph 3 of this annex. The 
annotation data shall be alphanumeric text, in accordance with Decision Number Nine. The 
items of information being annotated in the Text Segment shall be associated with an 
identifier which can be linked to an accompanying Open Skies ICD file. The identifier shall 
take the form of some alphanumeric string which refers to a set (group) of non-image data 
items and their definitions in the relevant Open Skies ICD file. A given Open Skies ICD file 
may contain several such groupings of non-image data items and their definitions. Unless 
otherwise agreed by an OSCC decision, the specific data representation, field-level 
formatting, and precision associated with a given item of information is wholly unrestricted 
by this decision, except for the limitation to string length (in terms of byte size) imposed by 
the fixed-width field pair paradigm described in paragraph 3 of this annex. 

Examples of Text Segment and TRE annotations are provided in Annex I of this 
decision. 

For Text Segment annotations the associated Text Segment Subheader shall be 
populated in accordance with the provisions of Annex D of this decision. 

Annotation data stored in a TRE shall be populated according to Table C. 1 in 
Annex C of this decision. The value of the TRETAG field is fully user-defined in this case, 
however, it is highly recommended that the six-character value chosen as the name of the 
TRE be co-ordinated with other States Parties so as to avoid name duplication amongst 
various data providers and to promote interoperability. The name chosen for the TRETAG 
field cannot equal a string of the form "ccSARn", where "cc" is an Open Skies country or 
group code (see Annex J), "SAR" is a literal string, and "n" is a single-digit version identifier 
from zero to nine, so as to avoid conflict with the standard "ccSARn" TRE template provided 
in Table C.2 of Annex C of this decision. 
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2. FIXED-WIDTH FIELD PAIR ANNOTATION INFORMATION FORMATTING 

For OSDDEF 1.2 formatted Image Data files, the following general structure shall be 
used when recording any non-image data: 

Any individual item of information which a State Party or group of States Parties 
wishes to annotate in the data portion of a user-defined Text Segment or TRE shall consist of 
a single 1 10-byte block of alphanumeric text referred to as a Field Pair. 

Each item of annotation data is separated into two basic parts. The first 30-byte part of 
the item of annotation, referred to as the Field Name, is used to record the name (identifier) 
assigned to the particular item of information. The second 80-byte part of annotation data 
item, referred to as the Field Value, is used to record the value assigned to the particular 
instance of the item of information. For example, if a data provider wanted to record that a 
particular temperature sensor reading was showing that the focal plane of a digital camera 
was at 13 degrees Celsius, then a corresponding user-defined annotation entry might look like 
the example provided in Figure 3: 



FP_TEMP_SENS_12 AAAAAAAAAAAAAAA + 0013 . 0000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 3: Notional Example of User-Defined Non-Image Data Conforming to the 
Fixed- Width Field Pair Format 

where the name of the item of information is given as "FPTEMPSENS12", the value 
reported by that temperature sensor is "+00 13. 0000", and the caret character, " A ", is used to 
represent a blank space. The name of the item of information, the formatting of the data 
value, and the specific units of measure and definition of the meaning of the item of 
information, its permissible range, and whether it is a required or conditional field are 
provided in the accompanying Open Skies ICD file. 

Based on the Open Skies ICD describing the annotation data, items of information 
being annotated by a State Party or group of States Parties can be grouped into a logical set of 
items related to a given sensor configuration, to a given observation mission, to a given 
aircraft platform, or any other logical grouping of related annotation items. Such a grouping 
of annotation items can be as small as one item or as large as desired by the data provider. A 
group of annotation items of information, as described in an ICD, is itself given an 
identifying name. The groupings, and their constituent items of information, must be fully 
and unambiguously described in an accompanying Open Skies ICD file. Group identifiers, as 
described in the Open Skies ICD file, shall be placed at the start and end of the series of 
annotation data items which comprise the group. A given group identifier, described by the 
corresponding ICD, is provided in a pair of bounding Field Pair entries; the opening Field 
Pair of the group shall have the Field Name "ICDStart" and the closing Field Pair of the 
group shall have the Field Name "ICDEnd". Both of these bounding Field Pairs contain the 
same Field Value - the name of the group of annotation items of information. This concept is 
illustrated in Figure 4: 



ICDStart AA 




' AA NORWEGIAN_NEAR_IR_CAMERA_TEMPERATURE_SENSOR_DATA_CELSIUS AA 


FP_TEMP_SENS. 


.01 


+ 0013.0230 


FP_TEMP_SENS_ 


.02 


+ 0013.0070 


FP_TEMP_SENS_ 


.03 


+ 0013.2000 


FP_TEMP_SENS_ 


.04 


+0013.2000 



-3 - 
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FP_TEMP_SENS_0 5 " A A 
FP_TEMP_SENS_0 6 A A A 
FP_TEMP_SENS_0 7 A A A 
FP_TEMP_SENS_0 8 " " A 
FP_TEMP_SENS_0 9 A A A 
FP_TEMP_SENS_1 0 " A A 
FP_TEMP_SENS_1 1 A A A 
FP_TEMP_SENS_12 " A A 

CAL TYPE" AAAAAAAAA 

DATE_OF_LAST_CAL AA 
ICDEnd AAAAAA " A '''^'' A 
ICDStart AAAAAAAAAA 
FP_TEMP_SENS_0 1 A A A 

FP TEMP SENS 02 A A 

FP TEMP SENS 0 3 A A A 

FP_TEMP_SENS_0 4 A A A 
FP_TEMP_SENS_0 5 A A A 
CAMERA_SERIAL_NUM A 
LAS T_CAL_DATE A A A 
ICDEnd AAAAAAAAAAAA 



A +0014.0010 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A +0013.9080 

A + 0012.0054 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A +0012.7801 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

" + 0012.8000 

"+0013.0003 

"+0013.0000 

A BLACKBODY-A A A A A A * A * A AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A 2010-MAR-15 AAAAAAA, ' A '' A '' AAAAAAA '"' A '' A '' A '' AAAAAAAA '' A '' A '' AAAAAA 
A NORWEGIAN_NEAR_IR_CAMERA_TEMPERATURE_SENSOR_DATA_CELSIUS A 
A NORWEGI AN_RGB_CAMERA_TEMPERATURE_SENSOR_DATA A aaaaaaaaaaaa 

A +010.70 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A +011.02 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A 775-34-SD/FG-990-lA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A 2009-OCT-03 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
"NORWEGI AN_RGB_CAMERA_TEMPERATURE_SENSOR_DATA A aaaaaaaa«a«» 



Figure 4: Notional Example of User-Defined Groupings of Non-Image Data Conforming 
to the Fixed-Width Field Pair Format 

In the preceding example, the Field Names "FP TEMP SENS O 1 " through 
"FP TEMP SENS 05" are used in two different groupings of annotation information. In the 
first grouping, the formatting of the temperature data allows for greater precision in the 
temperature readings being recorded. In the second grouping, the formatting of the 
temperature data associated with the same Field Names is more restricted, providing for less 
precise temperature values to be annotated in the Image Data file. The reuse of Field Names 
does not present a problem since every occurrence of a Field Pair is associated with a specific 
group name, as described in the accompanying ICD, which provides the needed information 
about the range and format of each specific Field Pair. Even though the specific field 
definitions, conditionality status, units of measure, and individual item of information 
formatting are provided in the accompanying Open Skies ICD file, OSDDEF -reading 
software can still readily present all of the annotation information stored in the OSDDEF file 
to the user since it is written in a text-based fixed-width field pair format. 

When populating a Text Segment or TRE with fixed width field pairs, individual field 
pairs in the Text Segment or TRE shall be concatenated, with no separators or delimiters 
between them, nor any terminators at the end of the collection of fixed width Field Pairs. 

It is recommended that the data provider incorporate some mechanism for reporting 
the units of measure and/or direction of application associated with an individual item of 
annotation information, if applicable, along with that value in the user-defined TRE or Text 
Segment. For example, even though the exact definition of the units of measure would have 
been provided in the accompanying ICD file, the individual temperature sensor readings in 
the previous example could have been described as being reported in degrees Celsius, versus 
some other measurement scale, by reporting that fact as part of the field name identifier or the 
value itself. A notional example of how this might look is provided in Figure 5 (for a Text 
Segment-based implementation): 



ICDStart AA 




' AA NORWEGIAN_NEAR_IR_CAMERA_TEMPERATURE_SENSOR_DATA AA - 


FP_TEMP_SENS_ 


_01-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_02-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_03-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_04-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_05-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_06-CELSIUS AAAA 


AAA +0014 




FP_TEMP_SENS_ 


_07-CELSIUS AAAA 


AAA +0013 




FP_TEMP_SENS_ 


_08-CELSIUS AAAA 


AAA +0012 
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TCMD PrMP (1Q I^E 1 ! C T IT C A A A A A A 

f r 1 Ejl'lr oLPJ o uy C£j^o±UC3 


A + 0 0 1 2 i 7801 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


cr> tpmd c^mc 1 n c tit o a a a a a a 


A + 0012 i 8000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


C^HIO 1 1 l^^T CTT7C AAAAAA 

p F 1 EMF SEN S 1 1— CHjIiDIUd 


A + 0013.0003 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


p F IEjMF SEN S 1 Z— CELSIUS 


A + 0013.0000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


CAL TYPE" AAAAAAAAAAAAAAAAAAAA 


A BLACKBODY— A A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


D ATE_0F_L AS T_C AL - GMT A A A A A A A A A 


A 2010-MAR-15 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


ICBEnd"""*"*""*""""" 


A NORWEGIAN NEAR IR CAMERA_TEMPERATURE SENSOR DATA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


I C D 5 1 s r ^ AAAAAAAAAAAAAAAAAAAAA 


A NORWE G I AN^RGB CAME RA^TEMP ERATURE SENS 0R_D AT A A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


FP_TEMP_SENS_0 l AAAAAAAAAAAAAA 


A + 009. 02 A degC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


FP_TEMP_SENS_02 " AAAAAAAAAAAAA 


A + 010 . 70 A degC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


FP_TEMP_SENS_0 3 A A AAAAAAAAAAAA 




FP_TEMP_SENS_0 4 AAAAAAAAAAAAAA 




FP_TEMP_SENS_0 5 AAAAAAAAAAAAAA 




CAMERA_SERIAL_NUM A AAAAAAAAAAA 


A 775-34-SD/FG-990-lA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


LAS T_CAL_DATE AAAAAAAAAAAAAAAA 


A 2009-OCT-03:UTC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


ICBEnd*""""""""*""*""" 


A NORWE G I AN^RGB C AMERA^TEMP ERATURE SENS OR_D AT A A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 5: Notional Example of User-Defined Groupings of Non-Image Data with Field 
Names and/or Field Values Incorporating Units of Measure Information 



When supplying treaty -required annotation information in an OSDDEF 1.2 compliant 
Text Segment or a TRE, the fixed-width field pair approach shall be used to report the 
annotation information as described in Figure 6. It is recommended that the data provider use 
the same Field Name entries provided in Annex E for treaty-required annotation. Note that 
the actual Field Value precisions which can be supported in the annotation data are supplied 
by other decisions. Figure 6 provides an example of an acceptable required annotation record 
implementation at the time of publication of this decision (in a TRE-based implementation). 



ICDStart AAA 
OSFLT AAAAAA 
OSDAT AAAAAA 
OSSNSR AAAAA 
SENS INS TAL A 
OSFCLL AAAAA 
OSDTG AAAAAA 
OSHAGL AAAAA 
OSLOC AAAAAA 
OSHDG AAAAAA 
OSSCAN AAAAA 
OSLDA AAAAAA 
OSNEAR AAAAA 
OSSWTH AAAAA 
OSPOL AAAAAA 
OSSPD AAAAAA 
OSDRFT AAAAA 
OSPTCH AAAAA 
OSROLL AAAAA 
FOCALRATIO" 
EXPOSURE" AA 
ICDEnd AAAAA 



A LATVIAN_TREATY_REQUIRED_ANNOTATION_INFORMATION A 

A LV13445 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
"20130825 

A TV AA HD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A INT-1-V-8B AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A 201308251012039 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A 10012M AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
A 60 . 2840N A 024 .673i E AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A 00 

A 000 

A 2 1 2 KM A A A A A A A A A A AA A A A A A A A AA A A A A A A A A A A A A A A A AA A A A A 
A 03.0R 

A 01.2D AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

A 01.8L 

A 002.5 

A 00. 01500 

A LATVI AN_TREATY_REQUI RED_ANNOTAT ION_INFORMAT ION A 



Figure 6: Notional Example of Required Non-Image Data using Specified Field Names 
and Acceptable Field Value Precisions in User-Defined Formats 



In this example, even though the data provider is recording treaty-required annotation 
information, this annotation information must be fully and unambiguously described in an 
accompanying ICD file. 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT TRE 
OVERFLOW DATA EXTENSION SEGMENT SUBHEADER 



Table G. 1 provides the population rules for an OSDDEF-compliant Tagged Record 
Extension Overflow Data Extension Segment Subheader and Segment data field. This 
construct is only allowed in OSDDEF 1.2 files. 



Table G.l: OSDDEF TRE OVERFLOW DATA EXTENSION SEGMENT FORMAT 



FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


DE 


DE 


2 A 


Data Extension Segment 
Subheader Identifier 


R 


DESID 


TREOVERFLOW 

(followed by blank spaces to fill 
all 25 characters) 


25 A 


Unique DES Type 
Identifier 


R 


DESVER 


01 


2N 


Version of DES Data 
Field Definition 


R 


DESSEC 


FOR OPEN SKIES PURPOSES 
ONLY 

(followed by blank spaces to fill 
all 167 characters) 


167 A 


Data Extension Segment 
Security Marking, per 
profile-specific security 
parameters 


R 


DESOFLW 


UDHD 
UDID 
IXSHD 
TXSHD 


6 A 


Identifier of Extension 
Field Which Overflowed 
into the DES 

(Field is present only 
when DESID = 
TRE OVERFLOW) 


C 


DESITEM 


000 (for DESOFLW = UDHD) 

001 (for DESOFLW = UDID or 
IXSHD) 

001 to 999 (for DESOFLW = 
TXSHD) 


3 N 


Number of the Data Item 
Overflowing into the 
DES 

(Field is present only 
when DESID = 
TREOVERFLOW) 


C 


DESSHL 


0000 


4N 


Length of Data 
Extension Segment 
Subheader User-Defined 
Fields, in bytes 

(Note: DESSHL = 0000 
when DESID = 
TRE OVERFLOW) 


R 
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FIELD 


VALUE 


SIZE 


DESCRIPTION 


TYPE 


The following fields only exist if the value of the DESSHL field is greater than OOOO 


DESSHF 


User-defined 


DESSHL 


User-Defined DES 


C 






(User-defined) 


Subheader Fields 










(Note: The DESSHF 










field is not used with 










TRE OVERFLOW 










DES) 




End of the DESSHL conditional fields 


End ofDES Subheader Fields 


Start ofDES Data 


DESDATA 


A series of TRE (which may or 


LDnnn 1 


Overflowed Series of 


C 




may not be User-Defined) which 


(User-defined) 


TRE 






have overflowed from the header 










or subheader field recorded in 










the DESOFLW field for the item 










recorded in the DESITEM field. 








End ofDES Data 



1 Size of the DESDATA field of the TREOVERFLOW DES should match the value recorded in the 

corresponding LDnnn field of the Main File Header. 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT MEDIA 
ANNOTATION FILE EXAMPLES 



This annex provides three notional examples of OSDDEF-compliant Media 
Annotation Files. Example File 1 is an OSDDEF 1.1 Media Annotation file for a medium 
containing imagery from a single configuration of a video camera sensor. Example File 2 is 
an OSDDEF 1.2 Media Annotation file for a medium containing imagery from a single 
configuration of an infrared frame imaging sensor. Example File 3 is an OSDDEF 1.2 Media 
Annotation file for a medium containing imagery from multiple configurations of various 
sensor systems. 

Table H. 1 and Table H.2 provide the File Headers and Text Segment Subheaders, for 
the three sample files respectively. 

(A) File Headers for OSDDEF Media Annotation Example 1 , Example 2 and 
Example 3 files. 

Table H.1: EXAMPLE OSDDEF MEDIA ANNOTATION FILE HEADERS 



Field 


Size 


Values for Fxample File 1 


Values for Example File 2 


Values for Example File 3 


FHDR 


4 


OSDE 


OSDE 


OSDE 


FVER 


5 


01.10 


01.20 


01.20 


CLEVEL 


2 


00 


00 


00 


STYPE 


4 


BFOl 


BFOl 


BFOl j 


OSTAID 


10 


OPEN SKIES 


OPEN SKIES 


OPEN SKIES 


FDT 


14 


20100312143015 


20110830113500 


20120102043000 


FTITLE 


80 


OPEN SKIES DIGITAL 


OPEN SKIES DIGITAL 


OPEN SKIES DIGITAL 






DATA EXCHANGE 


DATA EXCHANGE 


DATA EXCHANGE 






MEDIA ANNOTATION 


MEDIA ANNOTATION 


MEDIA ANNOTATION 


FSEC 


167 


FOR OPEN SKIES 


FOR OPEN SKIES 


FOR OPEN SKIES 






PURPOSES ONLY 


PURPOSES ONLY 


PURPOSES ONLY 


FSCOP 


5 


00000 


00000 


00000 


FSCPYS 


5 


00000 


00000 


00000 


ENCRYP 


1 


0 


0 


0 


OID 


45 


US 


CA 


RB 


FL 


12 


000000003539 


000000003319 


000000009039 


HL 


6 


000397 


000397 


000397 


NUMI 


3 


000 


000 


000 


NUMS 


3 


000 


000 


000 


NUMX 


3 


000 


000 


000 


NUMT 


3 


001 


001 


001 


LTSH001 


4 


0282 


0282 


0282 


LTOOl 


5 


02860 


02640 


08360 


NUMDES 


3 


000 


000 


000 


NUMRES 


3 


000 


000 


000 


UDHDL 


5 


00000 


00000 


00000 


XHDL 


5 


00000 


00000 


00000 



397 



(B) Text Segment Subheaders for OSDDEF Media Annotation Example 1, 

Example 2 and Example 3 files. Note that all three are identical except for the 
contents of the TXTDT field. 
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Table H.2: EXAMPLE OSDDEF MEDIA ANNOTATION FILE TEXT SEGMENT 
SUBHEADERS 



Field 


Size 


Values for Example File 1 


Values for Example File 2 


Values for Example File 3 


TE 


2 


TE 


TE 


TE 


TEXTID 


10 


MEDIA HDR 


MEDIA HDR 


MEDIA HDR 


TXTDT 


14 


20100312143015 


20110830113500 


20120102043000 


TXTITL 


80 


OPEN SKIES MEDIA 
ANNOTATION 


OPEN SKIES MEDIA 
ANNOTATION 


OPEN SKIES MEDIA 
ANNOTATION 


TSSEC 


167 


FOR OPEN SKIES 
PURPOSES ONLY 


FOR OPEN SKIES 
PURPOSES ONLY 


FOR OPEN SKIES 
PURPOSES ONLY 


ENCRYP 


1 


0 


0 


0 


TXTFMT 


3 


STA 


STA 


STA 


TXSHDL 


5 


00000 


00000 


00000 



282 



(C) Three examples of OSDDEF Text Data for OSDDEF Media Annotation files 
on exchange media containing OSDDEF Image Data files from (i) a single 
configuration of a video camera sensor collected during three observation 
periods (OPs), (ii) a single configuration of an infrared frame imaging sensor 
collected during two OPs, and (iii) multiple configurations of various sensor 
systems collected over different OPs. In accordance with Section VI, 
paragraph 2, of this decision, the Text Data portions of the three example Text 
Segments consist of a series of 1 10-character fixed-width field pair lines of 
text (30 characters for Field Name, 78 characters for Field Value, and two 
characters for the Carriage Return and Line Feed pair at the end of each line) 
as follows: 

(1) Media Identifier string, with Field Name of "MEDIA LABEL ID : " 
and Field Value of the form, "nnn_of_NNN", where "nnn" is a 3-digit 
number identifying the unique instance of the current medium, and 
"NNN" is a 3-digit number identifying the total number of media in the 
series, with both numbers being in the range 001 to 999; 

(2) Total number of observing States Parties, with a Field Name of 
"NUMBEROFOBSERVLNGSP:" and Field Value of the form, 
"NN", where "NN" is a 2-digit number in the range 01 to 99; 

Item (3) is repeated for each observing State Party associated with the observation 
flight mission: 

(3) Country/group code and observation flight reference number, with a 
Field Name of "OBSERVING PARTY CC/OSFLT:" and Field Value 
of "cc/OSyynnn", where "cc" is the appropriate code from Table J.l in 
Annex J of this decision (or otherwise approved 2-character code), "/" 
is a single solidus character (0x2F), and "OSyynnn" is the format for 
the associated observation flight reference number as defined in Treaty 
Annex B, Appendix 1, paragraph 1, and updated by OSCC Decision 
No. 4/10; 
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(4) Total number of observed States Parties for the observation flight, with 
a Field Name of "NUMBEROFOBSERVEDSP:" and Field Value 
of "NN", where "NN" is a 2-digit number in the range 01 to 99; 

Item (5) is repeated for each observed State Party associated with the observation 
flight mission for which Image Data files and/or ICD files were recorded on the current 
medium: 



(5) Observed State Party, with Field Name of "OBSERVEDPARTY:" 
and Field Value of "cc", where "cc" is the appropriate code from 
Table J. 1 in Annex J of this decision (or otherwise approved 
2-character code); 

(6) Date of observation flight, with a Field Name of 

"DATE OF OBSERVATION FLIGHT:" and Field Value of 
"CCYYMMDD", where "CCYY" is the 4-digit year, "MM" is the 
2-digit month (01 to 12), and "DD" is the 2-digit day (01 to 31); 

(7) Total number of sensor configurations used to produce Image Data 
files on the current medium, with a Field Name of 
"NUMBER_OF_SENSORS_USED:" and Field Value of "ss", where 
"ss" is a number from 01 to 99 when Image Data files are present on 
the medium or 00 when only ICD files are present on the medium; 



Items (8) through (16) are repeated as a set for each sensor configuration which 
produced Image Data files present on the medium (if the medium only contains ICD files, 
then items (8) through (16) are omitted): 



(8) Sensor reference number, with a Field Name of "SENSORJJSED:" 
and Field Value of "cc-rrrr-ssss", where "cc" is the appropriate country 
or group code from Table J. 1 in Annex J of this decision (or otherwise 
approved 2-character code), "rrrr" is one of the codes, "TVLI", 
"TVFI", "IRLS", "IRFI", "OP ", "OF ", or "SAR ", and "ssss" is a 
unique 4-digit reference number in the range 0000 to 9999; 

(9) Sensor description as defined in Treaty Annex B, Appendix 1, 
paragraph 2, with Field Name of "SENSOR DESCRIPTION:" and 
Field Value of "xxxxyy", where "xxxx" is one of the codes, "OP ", 
"OF ", "TV ", "IRLS", or "SAR ", and "yy" is one of the codes, "BI", 
"BM", "BP", "BR", "TA", "TD", or "HD"; 

(10) Sensor configuration (as reported in the Notification Formats field 
SENSINSTAL), with a Field Name of "SENSOR INSTALLATION:" 
and Field Value of "aaa-b-c-dd", where "aaa" is either "INT" or 
"POD", "b" is a number from 1 to 9 for internal installations or a letter 
"L", "R", or "C" for podded installations, "c" is a letter "V", "L", "R", 
or "F", and "dd" is a 2-digit number in the range 00 to 90 when "c" 
equals "V", "L", or "R", or two 1 -digit numbers in the range 1 to 9 
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when "c" equals "F", and the hyphen-minus characters, are used as 
value delimiters; 

(11) Focal length in millimetres, if applicable, with a Field Name of 
"SENSORFOCALLENGTH:" and Field Value of "fff ', where "fff 
is a 3-digit number in the range 001 to 999 or 3 blank spaces; 

(12) Total number of observation periods (OP) for which Image Data files 
related to the current sensor configuration are recorded on the medium 
(this number is the total number of OP across all legs of all segments 
of the observation flight for which Image Data files are present), with 
Field Name "NUMBER OF OBSERVATION PERIODS:" and Field 
Value of "pppppppppp", where "pppppppppp" is a 10-digit number in 
the range 0000000001 to 997901 1999 (supports up to 999 Segments x 
999 Legs x 9999 OP); 

Items (13) to (16) are repeated as a set for each observation period: 

(13) Segment/leg/observation period record, as defined in Format 14 with 
Field Name of "SEG LEG OP RECORD:" and Field Value of 
"aaa,bbb,cccc,ddddddd A eeeeeeee,ddddddd A eeeeeeee,CCYYMMDDhh 
mmss,CCYYMMDDhhmmss", where "aaa" is the segment in the 
range 001 to 999, "bbb" is the leg in the range 001 to 999, "cccc" is the 
OP in the range 0001 to 9999, "ddddddd" and "eeeeeeee" are the blank 
space, " A ", separated latitude and longitude values, respectively, of the 
starting and ending geographic co-ordinates for the OP, and 
"CCYYMMDDhhmmss" holds the starting and ending timestamps for 
the OP; 

(14) Total number of Image Data files produced by the current sensor 
configuration during the current OP, with Field Name of 
"NUMBER OF IMAGE FILES THIS OP : " and Field Value of 
"NNNNNNN", where "NNNNNNN" is in the range 0000001 to 
9999999; 

(15) Filename of the earliest-collected Image Data file written on the 
medium which is associated with the current OP, with Field Name of 
"FIRST FILENAME IN OP : " and a Field Value holding a filename 
with a size of up to 78 characters in length; 

(16) Filename of the latest-collected Image Data file written on the medium 
which is associated with the current OP, which Field Name of 
"LAST FILENAME IN OP : " and a Field Value holding a filename 
with a size of up to 78 characters in length; 

(17) Total size in bytes of all Image Data files present on the medium, with 
a Field Name of "TOTAL SIZE OF IMAGES IN BYTES:" and 
Field Value "NNNNNNNNNNNNNNNNNN" in the range 
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000000000000000383 to 999999999999999999, or all zeros if only 
ICD files are present on the medium; 

(18) Total number of ICD files on the current medium, with a Field Name 
of "NUMBER OF ICD FILES:" and Field Value of "NN", where 
"NN" is in the range 00 to 99; 

Item (19) repeats for each ICD file stored on the current medium (if the value of 
item (18) is 00, then item (19) is omitted): 

(19) ICD Filename, with Field Name of "ICDFILENAME:" and Field 
Value holding a filename with a size of up to 78 characters in length; 

Item (20) is present in the Media Annotation file only when the value of item (18) is 
not equal to 00. 

(20) Total size in bytes of all the ICD files present on the medium, with 
Field Name of "TOTAL SIZE OF ICDS IN BYTES:" and Field 
Value in the form "NNNNNNNNNN" in the range 0000000001 to 
9999999999. 



As stored in the three example Text Segments, the Media Annotation data, appears as: 
Example File 1 : 

In this example of a Media Annotation file, the observation mission consisted of a 
United States of America flight over the Ukraine. One sensor configuration was used to 
collect image data during this mission. The imagery written to this particular medium (which 
is the third medium out of a total of four) was collected during only the fifth segment of a 
six-segment mission. 

The fifth Segment had two legs, and during each leg the "TV" sensor was turned on. 
The "TV" sensor was turned on for two OPs during the first leg and 1 OP during the second 
leg. 

As displayed by a word processor (i.e., the CR/LF pair at the end of each Field Value 
produces a new line on the screen), the Text Segment data appears as: 



MEDIA_LABEL_ID I AAAAAAAAAAAAAAA^ Qf QJ^AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

NUMBER_OF_OBSERVING_SP : aaaaaaa 01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

OBSERVING_PARTY_CC/OSFLT : AAAAA DS/OS10212 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_OBSERVED_SP ; aaaaaaaa Q1 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
OBSERVED_PARTY : aaaaaaaaaaaaaaa da aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
DATE_OF_OBSERVATION_FLIGHT:^*^20100312 AA ^*^*^*^ AAAAAAA *^*^*^* AAAAAAA ^*^*^*^ AAAAAAA *^*^*^**^*^*^* AAAAAAA ^*^*^ 
NUMBER_OF_SENSORS_USED : aaaaaaa 01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

SENSOR_USED: AAAAAAAAAAAAAAAAAA OS-TVFI-2112 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_DESCRIPTION: AAAAAAAAAAA TV AA HD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_INSTALLATION : aaaaaaaaaa int _ 1 _ v _ 9 qaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
SENSOR_FOCAL_LENGTH ^aaaaaaaaa^jaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
NUMBER_OF_OBSERVATION_PERIODS : 0000000003 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 005 , 001 , 0001 , 4 60501N A 0301021E , 465255N A 0310722E , 20100312090700 , 20100312101700 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS10212US-TVFI-2112201003120907000_1.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS10212US-TVFI-2112201003121016047_100.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SEG_LEG_OP_RECORD: AAAAAAAAAAAA 005, 001, 0002, 4 65612N A 0312305E , 461727N A 0332040E, 20100312102600, 20100312111300 AA 
NUMBER_OF_IMAGE_FILES_THIS_OP: 0000100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS10212US-TVFI-2112201003121026143_101.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
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SEG_LEG_OP_RECORD : AA AAA 005 , 002 , 0001 , 4 6220 9N A 0335855E , 480335N A 0372148E , 20100312112300 , 20100312140000 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000213 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENftME_IN_OP : AAAAAAAAA OS10212US-TVFI-2112201003121123450_201.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENJ^ME_IN_OP: AAAAAAAAAA OS10212US-TVFI-2112201003121359155_413.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
TOTAL_SIZE_OF_IMAGES_IN_BYTES: 000000044604038012 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_ICD_FILES: AAAAAAAAAA 00 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 7: "File 1" Example of OSDDEF 1.1 Media Annotation Text Data 

Example File 2: 

In this example of a Media Annotation file, the observation mission consisted of a 
Canadian flight over Romania. One sensor configuration was used to collect image data 
during this mission. The imagery written to this particular medium (which is the first medium 
out of a total of five) was collected during the first and third segments of a three-segment 
mission. 

The first segment had one leg during which the "IRLI" sensor was turned on for just 
one OP. The third segment had one leg as well, during which the "IRLI" sensor was turned 
on for just one OP. 

As displayed by a word processor, the Text Segment data appears as: 



MEDIA_LABEL_ID: AAAAAAAAAAAAAAA 001_of_005 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_OBSERVING_SP: AAAAAAA 01 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
OBSERVING_PARTY_CC/OSFLT : ^a^a^cA/OS11665 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
NUMBER_OF_OBSERVED_SP: AAAAAAAA 01 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

DATE_OF_OBSERVATION_FLIGHT: AAA 20110830 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NtJMBER_OF_SENSORS_USED: AAAAAAA 01 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_USED: AAAAAAAAAAAAAAAAAA CA-IRLI-5555 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_DESCRIPTION: AAAAAAAAAAA IR AA HD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_INSTALLATION: AAAAAAAAAA POD-C-V-90 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_FOCAL_LENGTH: AAAAAAAAAA 120 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_OBSERVATION_PERIODS : 0000000002 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 001 , 0001 , 4 6 . 150N A 021 . 684E , 47 . 443N A 022 . 639E , 20110830030700 , 20110830041700 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000114 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS11665CA-IRLI-5555201108300307060_1 . BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS11665CA-IRLI-5555201108300416304_57857 .BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SEG_LEG_OP_RECORD: AAAAAAAAAAAA 003, 001, 0001, 44. 500N A 028 . 691E , 44. 374N A 02 6 . 370E, 20110830092600, 20110830101800 AA 
NUMBER_OF_IMAGE_FILES_THIS_OP: 0000102 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS11665CA-IRLI-5555201108300926149_409089.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP : AAAAAAAAAA OS11665CA-IRLI-5555201108301017160_4 60801 . bif aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
TOTAL_SIZE_OF_IMAGES_IN_BYTES: 000000000995336080 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_ICD_FILES ; aaaaaaaaa*01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

ICD_FILENAME: AAAAAAAAAAAAAAAAA CA-IRLI-5555_ICD_ver9C.TXT AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
TOTAL_SIZE_OF_ICDS_IN_BYTES: AA 0015108013 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 8: "File 2" Example of OSDDEF 1.2 Media Annotation Text Data 

Example File 3: 

In this example of a Media Annotation file, the observation mission consisted of a 
joint Russian Federation and Belarus group of States Parties and Swedish flight over the 
United States of America and Canada. Three different sensor configurations were used to 
collect image data during this joint mission. The imagery written to this particular medium 
was collected during three segments of the mission. 
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The first segment had two legs, and during each leg both the "TV" and "IRFI" sensors 
were turned on. The "IRFI" sensor was turned on for one OP during each leg, and the "TV" 
sensor was turned on for two OPs during the first leg and three OPs during the second leg. 

The second segment had one leg, and during this leg all three sensors ("TV", "IRFI", 
and "SAR") were turned on for a single OP. 

The third segment had one leg, and during this leg only the "TV" and "IRFI" sensors 
were turned on for a single OP. 

As displayed by a word processor, the Text Segment data appears as: 



MEDIA_LABEL_ID : aaaaaaaaaaaaaaaq 01 of 001 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
NUMBER_OF_OBSERVING_SP: AAAAAAA 02 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
OBSERVING_PARTY_CC/OSFLT: AAAAA RB/OS12100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
OBSERVING_PARTY_CC/OSFLT: AAAAA SE/OS12300 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_OBSERVED_SP: AAAAAAAA 02 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
OBSERVED_PARTY: AAAAAAAAAAAAAAA CA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
OBSERVED PART*Y * 

DATE_OF_OBSERVATION_FLIGHT: AAA 20120101 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_SENSORS_USED : aaaaaaaq3aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

SENSOR_USED: AAAAAAAAAAAAAAAAAA RB-TVFI-6716 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_DESCRIPTION: AAAAAAAAAAA TV AA HD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_INSTALLATION: AAAAAAAAAA INT-1-V-90 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_FOCAL_LENGTH: AAAAAAAAAA 125 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_OBSERVATION_PERIODS : 0000000007 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 001 , 0001 , 39 . 864N A 083 . 861W, 40 . 200N A 081 . 942W, 20120101090700 , 20120101101600 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201010907337_1.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011016522_100.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AAAAA 001 , 001 , 0002 , 40 . 250N A 081 . 663W, 40 . 472N A 080 . 389W, 20120101102600, 20120101111200 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201011026009_101.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011112111_200.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 002 , 0001 , 40 . 561N A 080 . 174W, 41 . 454N A 07 9 . 300W, 20120101112300 , 20120101124200 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP : 0000100 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201011123080_201.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011242123_300.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 002 , 0002 , 41 . 560N A 07 9 . 188W, 42 . 580N A 078 . 201W, 20120101125200 , 20120101142200 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000150 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201011252588_301.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011422522_450.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 002 , 0003 , 42 . 690N A 078 . 08 6W, 43 . 020N A 077 . 777W, 20120101143200 , 20120101150100 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000050 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201011432341_451.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011501089_500.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 002 , 001 , 0001 , 42 . 900N A 077 . 364W, 40 . 931N A 074 . 532W, 20120101163000 , 20120101184500 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP : 0000500 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201011630000_501.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-TVFI-6716201201011845009_1000.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 003 , 001 , 0001 , 45 . 443N A 075 . 543W, 46 . 770N A 071 . 421W, 20120101220300 , 20120102020000 AA 

NUMBER OF IMAGE F ILES THXS OP * O0OO5OO AAAAAAAAA/lAAAAAAAAAAAA/lAAAAAAAA/lA,VAAA ' VAAAAAAAAAAAAAAAAAAA/lAAAAAAA ' ,/lA/lA ''' 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-TVFI-6716201201012203132_1001.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP : AAAAAAAAAA OS12100RB-TVFI-6716201201020200065_1500 . BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_USED: AAAAAAA ^ — — "'■"'■'•'■'•KB-I'KFl-3323'-''"''" — — — ^*******a^ — — ^aaaaaaaa^ — — — ^aaaaaaaaaaaaaaa^ — — ^aaaaaaa 
SENSOR_DESCRIPTION: AAAAAAAAAAA IRFIHD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_INSTALLATION: AAAAAAAAAA INT-2-V-90 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_FOCAL_LENGTH : aaaaaaaaaa 115 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

NUMBER_OF_OBSERVATION_PERIODS: 0000000004 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SEG_LEG_OP_RECORD: AAAAAAAAAAAA 001, 001, 0001, 39. 885N A 083 . 77 6W, 40. 344N A 081 . 140W, 20120101091000, 20120101104500 AA 
NUMBER_OF_IMAGE_FILES_THIS_OP: 0000225 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-IRFI-3323201201010910333_1.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-IRFI-3323201201011045033_225.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 001 , 002 , 0001 , 40 . 800N A 07 9 . 922W, 42 . 090N A 078 . 671W, 20120101114500 , 20120101133900 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP: 0000275 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-IRFI-3323201201011145121_226.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-IRFI-3323201201011339093_500.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

SEG_LEG_OP_RECORD : AA AAA 002 , 001 , 0001 , 42 . 770N A 077 . 170W, 40 . 80 9N A 074 . 343W, 20120101163900 , 20120101185400 AA 

NUMBER_OF_IMAGE_FILES_THIS_OP : 0000500 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-IRFI-3323201201011639118_501.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-IRFI-3323201201011854062_1000.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SEG_LEG_OP_RECORD: AAAAAAAAAAAA 003, 001, 0001, 45 . 461N A 075 . 511W, 46 . 7 90N A 071 . 393W, 20120101220500, 20120102020200 AA 
NUMBER_OF_IMAGE_FILES_THIS_OP: 0000500 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-IRFI-3323201201012205057_1001 . BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-IRFI-3323201201020202488_1500.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SENSOR_USED: AAAAAAAAAAAAAAAAAA RB-SAR A -6116 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
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SENSOR_DESCRIPTION: aaaaaaaaaaa sar a hd aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
SENSOR_INSTALLATION : aaaaaaaaaa pod _ c _ l _ 75 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
SENSOR_FOCAL_LENGTH : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
NUMBER_OF_OBSERVATION_PERIODS : 0000000001 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
SEG_LEG_OP_RECORD: AAAAAAAAAAAA 002, 001, 0001, 42. 732N A 077 . 109W, 42. 551N A 07 6 . 855W, 20120101164200, 20120101165400 AA 
NUMBER_OF_IMAGE_FILES_THIS_OP: 0000500 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
FIRST_FILENAME_IN_OP : AAAAAAAAA OS12100RB-SAR_-6116201201011642031_1.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
LAST_FILENAME_IN_OP: AAAAAAAAAA OS12100RB-SAR_-6116201201011654582_255489.BIF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
TOTAL_SIZE_OF_IMAGES_IN_BYTES: 000000015935473000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
NUMBER_OF_ICD_FILES : aaaaaaaaaa 01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

ICD_FILENAME: AAAAAAAAAAAAAAAAA RB-SAR_-6116_ICD_001 .TXT AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
TOTAL_SIZE_OF_ICDS_IN_BYTES: AA 0005122009 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 9: "File 3" Example of OSDDEF 1.2 Media Annotation Text Data 
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OPEN SKIES DIGITAL DATA EXCHANGE FORMAT IMAGE DATA 

FILE EXAMPLES 



Table 1.1 through Table 1.7 provide five examples of OSDDEF Image Data files. 

1. Five example cases of recorded information for various sensor types: 

(A) TV1 : OSDDEF 1 . 1 image obtained from a 1024 (rows) x 1280 (columns) 
frame format, 12-bit black and white video imaging system, with a filename of 
OS15662EE-TVFI-0001201503121015003 1.BIF. This image is stored as a 
blocked image, with each block being a 1024 x 1024 pixel sub-image. Since 
1280 is not an even multiple of 1024, this storage mode requires pad pixels to 
make the stored image data consist of a set of complete blocks. Hence the 
value of LI001 for this image is 4194304 = 2 (blocks) x 1048576 
(pixels/block) x 2 (bytes/pixel); 

(B) TV2: OSDDEF 1.2 image from a line scanning (6000 elements per line) RGB 
colour video imaging system, with a filename of 
OS13333SE-TVLI-0001201303121015009_513.BIF. This image, with 

512 lines (rows), is unblocked; 

(C) IR: OSDDEF 1.1 image from a line scanning infrared detector 
(13000 elements per line), with a filename of 

OS14098PG-IRLS-0001201403121015002 1025.BIF. This image, with 
512 lines, is stored as a blocked image, with each block being a 5 12 x 6500 
pixel sub-image. Since 13000 is an even multiple of 6500, this storage mode 
does not require pad pixels. Hence LI001 is just NROWS x NCOLS for this 
image; 

(D) SARI: OSDDEF 1.2 image obtained from a synthetic aperture radar 
(13000 elements/slant range); with a filename of 

OS13053BX-SAR -0001201303121015004 1.BIF. As in Example C, for this 
blocked image, LI00 1 = NROWS x NCOLS; 

(E) SAR2: OSDDEF 1.1 image obtained from a synthetic aperture radar 
(16384 elements/slant range); with a filename of 

OS 12555RB-SAR -000220 12 1 11213141 54 0000000004097.BIF. This 
5 12-line image is stored as a blocked image, with each block being a 
512 x 4096 pixel sub-image. Since 16384 is an even multiple of 4096, this 
storage mode does not require pad pixels. Hence LI001 = NROWS x NCOLS 
for this image. 

2. OSDDEF example Image Data File Headers formatted according to the tables in 
Annex A of this decision. Note that a caret character, " A ", is used to indicate the presence of a 
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single blank space (0x20) within the portion of a field entry which contains valid data; 
trailing blank spaces are not always reported explicitly in the following tables in order to save 
space. 



Table 1.1: EXAMPLE OSDDEF IMAGE DATA FILE HEADERS 



Field 


Size 


TV1 


TV2 


IR 


SARI 


SAR2 


FHDR 


4 


OSDE 


OSDE 


OSDE 


OSDE 


OSDE 


FVER 


5 


01 . 10 


01.20 


01.10 


01.20 


01.10 


CLEVEL 


2 


00 


00 


00 


00 


00 


STYPE 


4 


BF01 


BF01 


BF01 


BF01 


BF01 


OSTAID 


10 


OPEISTSKIES 


OPEN A SKIES 


OPEN A SKIES 


OPEN A SKIES 


OPEN A SKIES 


FDT 


14 


20150312103000 


20130312103000 


20140312103000 


20130312103000 


20121112132011 


FTITLE 


80 


OPEN A SKIES A DIGI 
TAL A DATA A EXCHAN 
GE A IMAGE A DATA 


OPEN A SKIES A DIGI 
TAL A DATA A EXCHAN 
GE A IMAGE A DATA 


OPEN A SKIES A DIGI 
TAL A DATA A EXCHAN 
GE A IMAGE A DATA 


OPEN A SKIES A DIGI 
TAL A DATA A EXCHAN 
GE A I MAGE "DATA 


OPEN A SKIES A DIGI 
TAL A DATA A EXCHAN 
GE A IMAGE A DATA 


FSEC 


167 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES" 
PURPOSES A ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES" 
PURPOSES"ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FSCOP 


5 


00000 


00000 


00000 


00000 


00000 


FSCPYS 


5 


00000 


00000 


00000 


00000 


00000 


ENCRYP 


1 


0 


0 


0 


0 


0 


OID 


45 


EE 


SE 


IT 


NL 


RB 


FL 


12 


000004195561 


000009273510 


000006657257 


000006661385 


000008389959 


HL 


6 


000413 


000426 


000413 


000422 


000413 


NUMI 


3 


001 


001 


001 


001 


001 


LISH001 


6 


000439 


000468 


000439 


000439 


000533 


LI001 


10 


0004194304 


0009216000 


0006656000 


0006656000 


0008388608 


NUMS 


3 


000 


000 


000 


000 


000 


NUMX 


3 


000 


000 


000 


000 


000 


NUMT 


3 


001 


001 


001 


002 


001 


LTSH001 


4 


0282 


0846 


0282 


0282 


0282 


LT001 


5 


00123 


02420 


00123 


02420 


00123 


LTSH002 


4 








0282 




LT002 


5 








01540 




NUMDES 


3 


000 


001 


000 


000 


000 


LDSH001 


4 




0209 








LD001 














NUMRES 














UDHDL 


5 


00000 


00000 


00000 


00000 


00000 


XHDL 


5 


00000 


00000 


00000 


00000 


00000 



3. OSDDEF example Image Data file Image Segment Subheaders formatted according 
to Annex B of this decision. 



Table 1.2: EXAMPLE OSDDEF IMAGE DATA FILE IMAGE SEGMENT 
SUBHEADERS 



Field 


Size 


TV1 


TV2 


IR 


SARI 


SAR2 


IM 


2 


IM 


IM 


IM 


IM 


IM 


IID 


10 


0000000001 


0000000513 


0000001025 


0000000001 


0000004097 


IDATIM 


14 


20150312101500 


20130312101500 


20140312101500 


20130312101500 


20121112131415 


I INFO 


97 


OPEN A SKIES A I MAG 
E 


OPEN A SKIES A I MAG 
E 


OPEN"SKIES"IMAG 
E 


OPEN A SKIES A I MAG 
E 


OPEN A SKIES A I MAG 
E 


ISSEC 


167 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR"OPEN"SKIES" 
PURPOSES"ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR"OPEN"SKIES" 
PURPOSES"ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


ENCRYP 


1 


0 


0 


0 


0 


0 


ISORCE 


42 


EE-TVFI-0001 


SE-TVLI-0001 


PG-IRLS-0001 


BX-SAR"-0001 


RB-SAR A -0002 


NROWS 


8 


00001024 


00000512 


00000512 


00000512 


00000512 


NCOLS 


8 


00001280 


00006000 


00013000 


00013000 


00016384 


PVTYPE 


3 


INT 


INT 


INT 


INT 


INT 


I REP 


8 


MONO 


RGB 


MONO 


MONO 


MONO 


I CAT 


8 


VIS 


VIS 


IR 


SAR 


SAR 


ABPP 


2 


12 


08 


08 


08 


08 
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Field 


Size 


TV1 


TV2 


IR 


SARI 


SAR2 


P JUST 


1 


R 


R 


R 


R 


R 


ICORDS 


1 












NICOM 


1 


0 


0 


0 


0 


0 


IC 


2 


NC 


NC 


NC 


NC 


NC 


NBANDS 


1 


1 


3 


1 


1 


1 


IREPBAND1 


2 




R A 








ISUBCAT1 


6 


00 . 530 


00 . 630 


010.00 


004 .00 


004.10 


IFC1 




N 


N 


N 


N 


N 


IMFLT1 














NLUTS1 


1 


0 


0 


0 


0 


0 


IREPBAND2 


2 




G A 








I SUBCAT2 


6 




00 . 530 








IFC2 


1 




N 








IMFLT2 


3 












NLUTS2 


1 




0 








IREPBAND3 


2 




B A 








ISUBCAT3 


6 




00.450 








IFC3 


1 




N 








IMFLT3 


3 












NLUTS3 


1 




0 








ISYNC 


1 


0 


0 


0 


0 


0 


IMODE 


1 


B 


P 


B 


B 


B 


NBPR 


4 


0002 


0001 


0002 


0002 


0004 


NBPC 


4 


0001 


0001 


0001 


0001 


0001 


NPPBH 


4 


1024 


6000 


6500 


6500 


4096 


NPPBV 


4 


1024 


0512 


0512 


0512 


0512 


NBPP 


2 


16 


08 


08 


08 


08 


IDLVL 


3 


001 


001 


001 


001 


001 


IALVL 


3 


000 


000 


000 


000 


000 


ILOC 


10 


0000000000 


0000000000 


0000000000 


0000000000 


0000000000 


I MAG 


4 


1 . 00 


1.00 


1 . 00 


1 . 00 


1.00 


UDIDL 


5 


00000 


00003 


00000 


00000 


00000 


UDOFL 


3 




001 








IXSHDL 


5 


00000 


00000 


00000 


00000 


00094 


IXSOFL 


3 










000 


IXSHD 


Vari 










(Table 1.5) 




es 













4. Examples of OSDDEF Image Data file Text Segment Subheaders and text data 
formatted according to Annexes D and E of this decision. 



Table 1.3: EXAMPLE OSDDEF IMAGE DATA FILE TEXT SEGMENT 
SUBHEADERS 



(Subheaders associated with the first Text Segment appearing in the OSDDEF file.) 



Field 


Size 


TV1 


TV2 


IR 


SARI 


SAR2 


TE 






TE 




TE 




TEXTID 


10 


ANNOTATION 


ANNOTATION 


ANNOTATION 


ANNOTATION 


ANNOTATION 


TXTDT 


14 


20150312103000 


20130312103000 


20140312103000 


20130312103000 


20121112132011 


TXTITL 




OPEN A SKIES A IMAG 
E A ANNOTATION 


OPEN A SKIES A I MAG 
E ANNOTATION 


OPEN A SKIES A I MAG 
E A ANNOTATION 


OPEN A SKIES A I MAG 
E A ANNOTATION 


OPEN A SKIES A I MAG 
E A ANNOTATION 


TSSEC 




FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


FOR A OPEN A SKIES A 
PURPOSES A ONLY 


ENCRYP 


1 


0 


0 


0 


0 


0 


TXTFMT 


3 


STA 


STA 


STA 


STA 


STA 


TXSHDL 


5 


00000 


00564 


00000 


00000 


00000 


TXSOFL 


3 | 


000 j 






TXSHD 


TBD 




(Table 1.4 & Fig. 16) 









0282 + TXSHDL 

(Subheaders associated with the second Text Segment appearing in the OSDDEF file.) 
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(Subheaders associated with the first Text Segment appearing in the OSDDEF file.) 



Field 


Size 


TVl 


TV2 


IR 


SARI 


SAR2 


TXTITL 


80 








OPEN A SKIES A FIXE 
D A WIDTH A SAR A INF 
ORMAT I ON A P ARAME 
TERS 




TSSEC 


167 








FOR A OPEN A SKIES A 
PURPOSES A ONLY 




ENCRYP 


1 








0 




TXTFMT j 


3 








STA 




TXSHDL 


5 








00000 





0282 + TXSHDL 



(A) Image Annotation Text Data for the "TVl" Case Example: 

As displayed by a word processor, the "TVl" example image annotation Text Data 
portion of the Text Segment in the OSDDEF 1.1 formatted Image Data file would appear as 
shown in Figure 10 (where the caret, " A ", is used to indicate the presence of a blank space 
character in the Text Data). Note that there is no Carriage Return and Line Feed pair present 
at the end of this 123-character single line of text. 



OS156622 0150 312TV A A HDINT-3-V-871352 0150312 1015003130 0 0F55 A 4 508N A 037 A 3611E118 .20 900000000 AA 000NM00 .0L00.0U00 
.0L002. 800. 02000 



Figure 10: "TVl" Case Example of OSDDEF 1.1 Image Annotation Text Data 

(B) Image Annotation Text Data for the "TV2" Case Example: 

As displayed by a word processor, the "TV2" example fixed-width Field Pair image 
annotation Text Data portion of the Text Segment in the OSDDEF 1.2 formatted Image Data 
file would appear as shown in Figure 1 1 (where the caret, " A ", is used to indicate the presence 
of a blank space character in the Text Data). The Field Name (label) portion of each line is 
30 characters long and the Field Value portion of each line is 80 characters long, making each 
individual line equal to 1 10 characters. 



ICDStart AA 


AAAAAAAAAA SWEDISH A OPEN A 


SKIES A F IXED A WIDTH A IMAGE A ANNOTATION" A 


OSFLT AAAAAAAAAAAAAAA 


AAAAAAAAAA OS13333 AAAAAA 






OSDAT A A A A A A A A A A A A A A 


AAAAAAAAAA 20130312 AAAAA 






OSSNSR AAAAAAAAAAAAAA 


AAAAAA«AAA TV AA TD AAAAAAA 






SENSINSTAL AAAAAAAAAA 


AAAAAAAAAA INT-2-V-90 AAA 






OSFCLL AAAAAAAAAAAAAA 








OSDTG A A A A A A A A A A A A A 


AAAAAAAAAA 2013031210150 






OSHAGL A A A A A A A A A A A A A 


AAAAAAAAAA 13200F AAAAAAA 






OSLOC AAAAAAAAAAAAAAA 


AAAAAAAAAA 46 A 2703N A 030 A 


4804E AAAAAAAAAAAA ' 




OSHDG AAAAAAAAAAAAAAA 


036.5 






OSSCAN AAAAAAAAAAAAAA 


180 






OSLDA AAAAAAAAAAAAAAA 


00 






OSNEAR" A A A A A A A A A A A 


00 






OSSWTH AAAAAAAAAAAAAA 


ooo 






OSPOL AAAAAAAAAAAAAAA 








OSSPD AAAAAAAAAAAAAAA 


AAAAAAAAAA 000KM AAAAAAAA 






OSDRFT AAAAAAAAAAAAAA 


00. OR 






OSPTCH AAAAAAAAAAAAAA 


AAAAAAAAAA 00.0D AAAAAAAA 






OSROLL" A A A A A A A A A A A A 


AAAAAAAAAA 00. 0R AAAAAAAA 






FOCALRATIO AAAAAAAAAA 


AAAAAAAAAA 002.9 AAAAAAAA 






EXPOSURE A A A A A A A A A A 


AAAAAAAAAA 00.03308 AAAAA 






ICDEnd AAAAAAAAAAAAAA 


AAAAAAAAAA SWEDISH A OPEN A 


SKIES A FIXED A WIDTH A IMAGE A ANNOTATION AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figure 11: "TV2" Case Example of OSDDEF 1.2 Image Annotation Text Data 
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(C) Image Annotation Text Data for the "IR" Case Example: 

As displayed by a word processor, the "IR" example image annotation Text Data 
portion of the Text Segment in the OSDDEF 1.1 formatted Image Data file would appear as 
shown in Figure 12 (where the caret, " A ", is used to indicate the presence of a blank space 
character in the Text Data). Note that there is no Carriage Return and Line Feed pair present 
at the end of this single line of text. 



OS1409820140312IRLSHDPOD-C-V-8511520140312101500212000F3 9"5520N"032"5503E000 . 50 900000000""000KM00 . 0R00 . 0U0 0 
.0R003. 100. 00900 



Figure 12: "IR" Case Example of OSDDEF 1.1 Image Annotation Text Data 

(D) Image Annotation Text Data for the "SARI" Case Example: 

As displayed by a word processor, the "SARI" example's Treaty-required image 
annotation Text Data, stored in the first Text Segment in the OSDDEF 1.2 formatted Image 
Data file, would appear as shown in Figure 13 (where the caret, " A ", is used to indicate the 
presence of a blank space character in the Text Data). The Field Name (label) portion of each 
line is 30 characters long and the Field Value portion of each line is 80 characters long, 
making each individual line equal to 1 10 characters. 



ICDStart"" 




A BENE LUX A OP EN A 


SKIES A F IXED" WIDTH" IMAGE" ANNOTATION" A 


OSFLT """""""""""""" " 




A OS13053 AAAAAA 












OSDAT """"""""""""""" 




"20130312 












OSSNSR" AAAA """"""""" 




A SAR A HD AAAAAAA 












SENSINSTAL" " ~"~""" A " 




A INT-2-L-65 AAA 












OSFCLL AA * AAA " A " AAAAA 




A 000 












OSDTG A A A A A A A A A A AA A A " 




"2013031210150 


04""" 










OSHAGL """""""""""""" 




A 05000M AAAAAAA 












OSLOC AAAAAA """"""" AA 




A 42 A 4008N A 023 A 


2031E"""""" 








OSHDG A A A A A A """""""" A 




A 180 .2 AAAAAAAA 












OSSCAN" """"""""""""" 




A 000 












OSLDA"" """"""""""""" 
















OSNEAR" """"""""""""" 




A oi 












OS SWTH" """""""""""" " 




A 003 












OSPOL""""""""""""""" 




A HV AAAAAAAAAAA 












OSSPD"" """"""""""""" 




A 320KM AAAAAAAA 












OSDRFT """"""""""""" " 




A 02R AAAAAAAAAA 












OSPTCH A A A A A AA A A " A A A " 




A 01D AAAAAAAAAA 












OSROLL """"""""""""" " 




A 01R AAAAAAAAAA 












FOCALRATIO"""""""""" 




A 000.0 












EXPOSURE A A AAAAAAAAAA 




A 00. ooooo 












ICDEnd" AAAA """"""" AA 




A BENE LUX A OP EN A 


SKIES"FIXED"WIDTH"IMAGE"ANNOTATION" """""""""""""""""""" """""""""""" 



Figure 13: "SARI" Case Example of OSDDEF 1.2 Image Annotation Text Data 

As displayed by a word processor, the "SARI" example's fixed-width 
implementation of SAR information parameter annotation Text Data, stored in the second 
Text Segment in the OSDDEF 1.2 formatted Image Data file, would appear as shown in 
Figure 14 (where the caret, " A ", is used to indicate the presence of a blank space character in 
the Text Data). The Field Name (label) portion of each line is 30 characters long and the 
Field Value portion of each line is 80 characters long, making each individual line equal to 
110 characters. Note that in the fixed-width field pair implementation used with this 
particular OSDDEF 1.2 formatted example Image Data file there is no requirement for a 
Field Name/Field Value pair which would be equivalent to the SARUDDATA field of the 
"ccSARn" TRE template (see Table C.2 in Annex C of this decision). This is due to the fact 
that in OSDDEF 1.2 any additional user-defined annotation information can be provided in a 
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separate user-defined Text Segment or user-defined TRE (which would then be described in 
an accompanying ICD file). 



ICDStart AAAA 












AAA OPEN A SKIE S A F IXED 


A WIDTH A S AR A I NFORMAT ION A PARAMETERS A A A A 






















SARTYP A A A * A A 












AAA LINEAR A FM A CHIRP A 
























S ARRT A A A A A A A 




































SARSLANTMN A A 












AAA 005250.0 
























S ARF W A A A A A A A 












AAA W AAAAAAAAAAAAAAA 
























SAROPFREQ AAA 












AAA 00003.00 
























SARBANDTX A A A 












AAA 000.00 
























SARDUR AAAAAA 












aaa oo.oooo aaa 
























SARNP 




































SARPULSES AAA 












AAA 0000.000 
























SARVEL AAAAAA 












AAA 000.0000 
























SARAAB AAAAAA 












AAA 0.0000 
























SARRANNUM AAA 












AAA 0.0000 
























ICDEnd AAAAAA 












AAA OPEN A SKIES A FIXED 


A WIDTH A S AR A I NFORMAT ION A PARAMETERS A A A A 























Figure 14: "SARI" Case Example of OSDDEF 1.2 SAR Information Parameter 
Annotation Text Data 

(E) Image Annotation Text Data for the "SAR2" Case Example: 

As displayed by a word processor, the "SAR2" example image annotation Text Data 
portion of the Text Segment in the OSDDEF 1.1 formatted Image Data file would appear as 
shown in Figure 15 (where the caret, " A ", is used to indicate the presence of a blank space 
character in the Text Data). Note that there is no Carriage Return and Line Feed pair present 
at the end of this single line of text. 



OS1255520121112SAR A HDPOD-C-R-5500020121112131415405010M43 . 1200N A 077. 67 0 3W135 . 2 0001001008W310KM00 . 0R01 . 2U01 
.9L000. 000. 00000 



Figure 15: "SAR2" Case Example of OSDDEF 1.1 Image Annotation Text Data 

5. Example field record expansions for the various TRE used in these example cases. 

The example TRE provided in Table 1.4 and Table 1.5 are used to encode items such 
as additional observation flight reference numbers associated with an image collection 
(user-defined OSMFLT TRE recorded in the TXSHD field of the file's Text Segment 
Subheader) and SAR Information Parameters (notional implementation of the "ccSARn" 
TRE, RBSAR1, recorded in the IXSHD field of the file's Image Segment Subheader). Both 
of these example TRE are notional and do not represent any actual TRE used by any State 
Party or group of States Parties. An additional example user-defined TRE is presented in 
paragraph 6 of this annex, since it is recorded in a TRE OVERFLOW DES. 

(A) User-defined TRE stored in the TXSHD field in the "TV2" Case Example: 

Table 1.4: "TV2" CASE EXAMPLE OF A USER-DEFINED TAGGED RECORD 
EXTENSION FOR RECORDING OBSERVATION FLIGHT REFERENCE 
NUMBERS 



Field Name 


Size 


Field Value 


Comments 


TRETAG 


6A 


OSMFLT 


Unique Ta^ed Record Extension Identifier. Notional implementation of 
user-defined TRE to record additional Observation Flight Reference 
Numbers associated with a mission; note, this example implementation 
does not represent or imply any actual implementation being used by 
either Sweden or Poland. 
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Field Name 


Size 


I?:. .1,1 * 

field Value 


Comments 


TREL 


5N 


00440 to 99990 


Total Length of the Tagged Record Extension. Length of the TRE in bytes. 
Note: The fixed-width field pair construct ensures that the TREL value is a 
multiple of 1 1 0 bytes. 


ICD_START_LABEL 


30 A 


ICDStart 


Starting ICD Label. Together with the contents of ICD START VALUE, 
identifies the start of the ICD used by Sweden to specify the number of 
OSFLT fields associated with this flight. 


ICD_START_VALUE 


80 A 


Num_OSFLT_Sweden 


Starting ICD Identifier. Together with the contents of 
ICD_START_LABEL, identifies the start of the ICD used by Sweden to 
specify the number of OSFLT fields associated with this flight. 


NUM_OSFLT_LABEL 


30 A 


NUM_OSFLT 


Number of OSFLT Field Label. Fixed-width field pair label associated 
with the contents of the NUM_OSFLT_VALUE, field. 


NUM OSFLT VALU 
E 


80 A 


001 to 906 (followed by 
77 blank spaces (0x20)) 


Number of OSFLT Field Value. The number of OSFLT numbers 
associated with this flight and reported in the Notification Formats. 

Note: This field is treated as an alphanumeric string, not a numeric string, 
and is right-padded with blank spaces to conform to the fixed-width field 
pair construct. 


Number of Observation Flight Reference Numbers Loop; Loop runs from nnn = 00 J to NUM_OSFLT. 


OSFLT_LABELnnn 


30 A 


OSFLTnnn 


OSFLT Field Label. Fixed-width field pair label associated with the 
contents of the OSFLT VALUEnnn field and where nnn matches the 
current loop iteration value from 001 to 906. 


OSFLT_VALUEnnn 


80 A 


OSyyxxx (followed by 
73 blank spaces (0x20)) 


OSFLT Field Value. An individual observation flight reference number 
associated with the mission. The value is a 7-character Observation Flight 
Reference Number (OSFLT) as defined by OSCC.DEC/4/10, where the 
first 2 characters are the literal string "OS", "yy" is the last 2 digits of the 
calendar year of the flight, and "xxx" is a unique 3-digit number that 
identifies the flight. The first OSFLT entered in this TRE is the primary 
OSFLT for the mission. 


End of the Number of Observation Flight Reference Numbers Loop. 


ICDENDLABEL 


30 A 


ICDEnd 


Ending ICD Label. Together with the contents of ICD END VALUE, 
identifies the end of the ICD used by Sweden to specify the number of 
OSFLT fields associated with this flight. 


ICD_END_VALUE 


80 A 


Num_OSFLT_Sweden 


Ending ICD Identifier. Together with the contents of ICD END LABEL, 
identifies the end of the ICD used by Sweden to specify the number of 
OSFLT fields associated with this flight. 



The data actually recorded in this example instance of the "OSMFLT" user-defined 
TRE for the "TV2" case is provided in Figure 16. This annotation example consists of a 
contiguous block of 561 bytes of data including the TRETAG and TREL field values and the 
fixed-width field pair formatted user-defined data content. This instance of the "OSMFLT" 
TRE is reporting that there are two observation flight reference numbers associated with this 
Image Data file, the primary one being assigned to Sweden and the secondary one being 
assigned to Poland, describing a joint mission between these two States Parties using a sensor 
certified by Sweden. 



OSMFLT0 0 55 0 ICDStart" 


aaaaaaaa A A Nuni OSFLT Sweden A A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 




002 


• ....•..,..». osflt001 ™«.a.a.a 


OS13098 


AAAAfl An A" A" A A AQgp^QQ2 """AflAAAfl 


AAAAAAAAAAAAA OS13412 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAJCQJ-^AAAAAAAAAA 


AAAA AAAAAAAA A A NllKl OSFLT SWedei! " A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 







Figure 16: "TV2" Case Example Population of a User-Defined TRE for Recording 
Multiple Observation Flight Reference Numbers 
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(B) RBSAR1 TRE stored in the IXSHD field in the "SAR2" Case Example: 



Table 1.5: "SAR2" CASE EXAMPLE POPULATION OF THE SAR INFORMATION 
PARAMETERS TAGGED RECORD EXTENSION 



r lelcl 




VolUc 


Comments 


TT) i — r A /■ ' 
1 Kb 1 AO 


6 


n T > l A Ti 1 

KlJbAKl 


Notional implementation of the "ccSARn" TRE (see Annex C); note, this 
example implementation does not represent or imply any actual 

llll^lClllCllLdllUll UClllJ^ USGU Uy U1G IVUSSldll 1 CUGldllUll CU1U UCltllLlS gllJU|l 

of States Parties. 


TREL 


5 


00080 


Since the size is equal to 00080, there are no bytes of User-Defined data in 
this notional RBSAR1 TRE. This is a requirement for OSDDEF 1 . 1 SAR 
Image Data files. 


SARTYP 


20 


LINEAR FM CHIRP 


Designation of a straight-flying SAR using a linear FM chirp as the 
emitted pulse. 


SARRT 


1 


R 


Indicates that the SARSLANTMN field holds the range to first sample. 


SARSLANTMN 


8 


04000.00 


Range to first sample in metres. 


SARFW 


1 


F 


Indicates that the SAROPFREQ field holds the SAR operating frequency. 


SAROPFREQ 


8 


09000.00 


Emitted pulse carrier frequency in MHz. 


SARBANDTX 


6 


040.00 


Emitted pulse bandwidth in MHz. 


SARDUR 


7 


10.0000 


Emitted pulse duration in microseconds. 


SARNP 


1 


P 


Indicates that the SARPULSES field holds the pulse repetition frequency. 


SARPULSES 


8 


2000.000 


Pulse repetition frequency in Hz. 


SARVEL 


8 


010.0000 


Along-track platform velocity in metres per second. 


SARAAB 


6 


0.0523 


Azimuthal antenna beamwidth in radians. 


SARRANNUM 


6 


1.0000 


Number of range samples generated per metre of slant range. 



91 



RBSAR10 00 80LINEAR''FM- S CHIRP''"''"''R04000 . OOF09000. 00040. 0010. 0000P2000. 000010. 00000. 05231. 0000 



Figure 17: "SAR2" Case Example of ccSARn TRE 

6. Example Data Extension Segment (DES) Subheaders. 

Table 1.6 and Table 1.7 are provided to illustrate the concept of TRE overflow from a 
TRE-holding Header or Subheader field into a TREOVERFLOW DES. The field 
DESDATA, from Table G. 1 in Annex G of this decision, is user-defined in both size and 
value and is entirely dependent upon the definition of the actual Tagged Record Extensions 
which overflowed from the corresponding UDHD, UDID, IXSHD, or TXSHD field. (Note: 
For historical reasons, the TRE-holding XHD field in the File Header is not used in 
OSDDEF.) 

The only example OSDDEF Image Data file provided in this decision which makes 
use of TRE overflow is the "TV2" case example. Strictly speaking, the size of the single TRE 
involved, which is described by Table 1.7, is not sufficiently large enough to require overflow 
to a TRE OVERFLOW DES. However, even when overflow is not required based on 
inherent field-size limitations, it may still be used to record TRE, at the discretion of the data 
provider. Since DES are the last types of data structures written in an OSDDEF file, it may be 
in a data provider's best interest to record any TRE data generated during the image 
collection process in an artificially overflowed TRE OVERFLOW DES, as opposed to one 
required by circumstance, to best meet file production timelines in the processing chain. 
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Table 1.6: EXAMPLE OSDDEF TRE_OVERFLOW DATA EXTENSION SEGMENT 



Field 


Size 


TV1 


TV2 


IR 


SARI 


SAR2 


DE 


2 












DESID 


25 




TRE_OVERFLOW 








DESVER 


2 




01 








DESSEC 


167 




FOR A OPEN A SKIES 
^PURPOSES^ONLY 








DESOFLW 


6 




UDID 








DESITEM 


3 




001 








DESSHL 


4 




0000 








DESDATA 


vari 
es 


! (Table 1.7) j j 





0209 + DESDATA value 



Table 1.7: "TV2" CASE EXAMPLE OF A USER-DEFINED TAGGED RECORD 
EXTENSION FOR RECORDING ENGINEERING FLIGHT NON-IMAGE DATA 



Field 


Size 


Value 


Comments 


TRETAG 


6A 


SEDATA 


Unique Tagged Record Extension Identifier. This 
identifier is for example use only and does not 
represent any actual TRE used under the Treaty. 


TREL 


5N 


00770 to 99770 


Total Length of the Tagged Record Extension. 
Length of the TRE in bytes. Size of TRE is limited by 
the fixed-width field pair implementation and the 
looping construct to certain multiples of 1 10 bytes. 


ICD_START_LABEL 


30 A 


ICDStart 


Starting ICD Label. Together with the contents of 
ICD_START_VALUE, identifies the start of the ICD 
used by Sweden to specify TV camera engineering 
data, at 60-second intervals. 


ICD_START_VALUE 


80 A 


TV_Eng_Data_Sweden 


Starting ICD Identifier. Together with the contents of 
ICD_START_LABEL, identifies the start of the ICD 
used by Sweden to specify TV camera engineering 
data, at 60-second intervals. 


NUM_DATA_SETS_LABEL 


30 A 


NUM_DATA_SETS 


Number of Data Sets Field Label. Fixed-width field 
pair label associated with the contents of the 
NUM_DATA_SETS_VALUE, field. 


NUM_DATA_SETS_VALUE 


80 A 


001 to 226 (followed by 77 blank 
spaces (0x20)) 


Number of Data Sets Field Value. The number of 
flight engineering data sets associated with the TVLI 
RGB sensor during this observation flight. 

Engineering flight data is provided for up to 

226 instances in time during operation of the TVLI 

RGB colour image sensor. 

Note: This field is treated as an alphanumeric string, 
not a numeric string, and is right-padded with blank 
spaces to conform to the fixed-width field pair 
construct. 


Number of Engineering Flight Data Sets Loop; Loop runs from 001 to NUM_DATA_SETS 


READ_TIME_LABELnnn 


30 A 


READJTMEnnn 


Read Time Field Label. Fixed-width field pair label 
associated with the contents of the 
READ_TIME_VALUEnnn field and where nnn 
matches the current loop iteration value from 001 to 
226. 


READ_TIME_VALUEnnn 


80 A 


CCYYMMDDhhmmss (followed 
by 66 blank spaces (0x20)) 


Read Time Field Value. A timestamp associated with 
an individual engineering data set. The value is a 
14-character timestamp where CCYY is the year in 
the range 1991 to 9999, MM is the month from 01 to 
12, DD is the day from 01 to 31, hh is the hour from 
00 to 23, mm is the minute from 00 to 59, and ss is 
the second from 00 to 59. 


FP_TEMP_LABELnnn 


30 A 


FOCAL_PLANE_TEMPnnn 


Focal Plane Temperature Field Label. Fixed-width 
field pair label associated with the contents of the 
FP_TEMP_VALUEnnn field and where nnn matches 
the current loop iteration value from 001 to 226. 
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Field 


Size 


Value 


Comments 


FP_TEMP_VALUEnnn 


80 A 


iddd.ddd (followed by 72 spaces) 


Focal Plane Temperature Field Value. A temperature 
reading taken at the focal plane at the timestamp 
provided in the corresponding 
READ_TIME_VALUEnnn field. The value is an 
8-character string representing a signed floating point 
value in the range -273.150 to +999.999 degrees 
Celsius. 


VOLT_LVL_LABELnnn 


30 A 


VOLTAGE_LEVELnnn 


Voltage Level Reading Field Label. Fixed-width field 
pair label associated with the contents of the 
VOLT_LVL_VALUEnnn field and where nnn 
matches the current loop iteration value from 001 to 
226. 


VOLT_LVL_VALUEnnn 


80 A 


±dd.dddddd (followed by 70 
spaces) 


Voltage Level Reading Field Value. A voltage 
reading across the voltage supply at the timestamp 
provided in the corresponding 
READ_TIME_VALUEnnn field. The value is a 
10-character string representing a signed floating 
point value in the range -99.999999 to +99.999999 
volts. 


AMP_LABELnnn 


30 A 


AMPERAGEnnn 


Amperage Measurement Field Label. Fixed-width 
field pair label associated with the contents of the 
AMP_VALUEnnn field and where nnn matches the 
current loop iteration value from 001 to 226. 


AMP_VALUEnnn 


80 A 


id.dddddd (followed by 71 spaces) 


Amperage Measurement Field Value. A measure of 


the amperage flowing from the power supply at the 
timestamp provided in the corresponding 
READ_TIME_VALUEnnn field. The value is a 
9-character string representing a signed floating point 
value in the range -9.999999 to +9.999999 amperes. 


End of the Engineering Flight Data Sets Loop 


ICDENDLABEL 


30 A 


ICDEnd 


Ending ICD Label. Together with the contents of 
ICD_END_VALUE, identifies the end of the ICD 
used by Sweden to specify TV camera engineering 
data. 


ICD_END_VALUE 


80 A 


TV_Eng_Data_Sweden 


Ending ICD Identifier. Together with the contents of 
ICD_END_LABEL, identifies the end of the ICD 
used by Sweden to specify TV camera engineering 
data. 



The data actually recorded in this example instance of the "SEDATA" user-defined 
TRE for the "TV2" case is provided in Figure 17. This annotation example consists of a 
contiguous block of 53,141 bytes of data including the TRETAG and TREL field values and 
the fixed-width field pair formatted user-defined data content. This instance of the 
"SEDATA" TRE is reporting engineering data measurements every second for 60 seconds 
prior to the start of the imaging operation and 60 seconds after the start of the imaging 
operation for a total of 120 data set entries. 



SEDATA53130ICDStart"" AA ""''"''" / - A/ - A/ - A/ "' s "TV_Eng_Data_Sweden AAA 

,.«..„,,A,» [1IJM j aTS J ETS »».«.«..„A™««. 120 A.,.,...,».«.«.», 

aaaaaaaaaaa A "^^^[) TIME ooi"''"'''-''" / - A/ -" s/ - A/ - A "''"20130312101400"''"''" s 

AAAAAAAAAAAA A A F QCAL_P LANE_TEMP 0 0 1 AAAAAAAA A A A + Q ^ _ Q Q £ A A A A A A A A A A 
AAAAAAAAAAAAA A A L J A Q E _ L £ V£ J, Q Q ^AAAAAAAAAAAAA^^Q^J^AAAAAAA 

AAAAAAAAAAAAAAAA flM p ERAGE QQ 1 AAAAAAAAAAAAAAAAAAA + Q ^ jj , jjj . ... . 
AAAAAAAAAAAAAAAAA READ _ TIME002 AAAAAAAAAAAAAAAAAA 20130312101401 A 



(Note: The intervening 51828 bytes of data have been removed) 



READ_TIME120" A " A " AAAAAAAAAA ""20130312101559"''" / - A/ - A/ - A/ -'' 

"FOCAL PLANE TEMP 12 0 a aaaaaaaaaa_|_qi^ ^ q 22 aaaaaaaaaaaaaaaa 

A "VOLTAGE_LEVEL12 0 A "'- A '- A '- A """ + 11.000019" A """ / - A/ - A/ - A/ -" 

AAA flMpERAGE12 QAAAAAAAAAAAAAAAAAAA +0 QQjgggAAAAAAAAAAAAA 
AAAAJ CDEnd AAAAAAAAAA AAAAAAAAAAAAA A TV ^ En g^ Data ^ Sweden AAA 



Figure 18: "TV2" Case Example Population of a User-Defined TRE for Recording 
Engineering Flight Non-Image Data 
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OPEN SKIES COUNTRY CODES AND GROUP CODES 



Table J. 1 provides the current list of two-character country codes and group codes 
approved by States Parties and groups of States Parties for use in OSDDEF files at the time 
of publication of this decision. States Parties and groups of States Parties have the right to 
update the codes they wish to use to identify themselves; as such, the list presented in 
Table J. 1 should not be considered definitive or binding. The chairperson of the Informal 
Working Group on Sensors (IWGS) may choose to maintain an up-to-date list of approved 
codes for reference. 

In the event that a new State Party accedes to the Treaty, it is suggested that an initial 
code be assigned to that State Party which matches the two-character country code currently 
defined in the International Standard Codes for the representation of names of countries and 
their subdivisions - Part 1: Country Codes (ISO 3166-1), unless this code conflicts with an 
existing code already in use by a current State Party or group of States Parties. 

Table J.l: COUNTRY AND GROUP CODES FOR USE IN OSDDEF FILES 



COUNTRY/GROUP NAME 


OSDDEF CODE 


Belarus 


BY 


Belgium 


BE 


Benelux group of States Parties 


BX 


Bosnia and Herzegovina 


BA 


Bulgaria 


BG 


Canada 


CA 


Croatia 


HR 


Czech Republic 


CZ 


Denmark 


DK 


Estonia 


EE 


Finland 


FI 


France 


FR 


Georgia 


GE 


Germany 


DE 


Hellenic Republic (Greece) 


GR 


Hungary 


HU 


Iceland 


IS 


Italy 


IT 


Latvia 


LV 


Lithuania 


LT 


Luxembourg 


LU 


Netherlands 


NL 


Norway 


NO 


Pod Group 


PG 
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COUNTRY/GROUP NAME 


OSDDEF CODE 


Poland 


PL 


Pnrtii cral 


PT 


R omariia 

1 V W 1 1 1 1.4 1 1 1 C4 


RO 


Russian FpHpration 


RU 


Russian FpHpratinn and Rplams crrmir> of Sltafps Parties 


RB 


Sllnvalc Rpniihlif* 


SK 


Sllovpnia 


SI 


Spain 


ES 


Sweden 


SE 


Turkey 


TR 


Ukraine 


UA 


United Kingdom 


GB 


United States of America 


US 



